LIBBSD

[Kirspel, Kevin]

I have rewritten the kern_timeout.c module to use individual RTEMS timers per callout/timeout function.  My Idle task CPUUSE is now 99.9%. I still need to validate all the functionality of the kern_timeout.c module with a timeout01 test in the testsuite.  I don't think the existing kern_timeout.c module currently supports all the functionality that is used in Freebsd (callouts/timeouts on a particular CPU core).  Right now everything is processed on CPU core 0 because of the way the RTEMS timer server works.  My version excludes all the SMP stuff and silently places all timeouts on CPU core 0.  We could probably support the callouts/timeouts on a particular CPU core if we update the RTEMS timer code but I don't think it is a feature that most people would use.

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510-4444 ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-----Original Message-----
From: devel [mailto:devel-bounces at rtems.org] On Behalf Of Kirspel, Kevin
Sent: Friday, June 30, 2017 2:08 PM
To: devel at rtems.org
Subject: RE: LIBBSD

Just some quick numbers.  LPC3250 running at 208 MHz, 64MB RAM, 512MB FLASH.

Case #1: Disable the RTEMS callout timer in LIBBSD (kern_timeout.c) IDLE Task CPUUSE: 99.430% TIME Task CPUUSE: <0.001%

Case #2: Enable the RTEMS callout timer but do not call "callout_process()" (the timer service routine just resets the timer and quits) .
IDLE Task CPUUSE: 93.144%
TIME Task CPUUSE: 6.282%

So just processing the 1 tick RTEMS timer in LIBBSD's kern_timeout.c takes up 6% of the CPU processing time.

Case #3: Normal callout processing
IDLE Task CPUUSE: 87.116%
TIME Task CPUUSE: 12.672%

Below are the callout functions that are being executed.  The number beside each function is the average number of clocks it took to execute (13MHz base clock).

ipport_tick - 370/28us
pffasttimo -  930/72us
pfslowtimo - 5600/431us
lpe_tick - 4200/323us
_bsd_nd6_timer - 650/50us
usb_power_wdog - 1000/80us
ohci_rhsc_enable - 400/31us

Kevin Kirspel
Electrical Engineer - Sr. Staff
Idexx Roswell
235 Hembree Park Drive
Roswell GA 30076
Tel: (770)-510-4444 ext. 81642
Direct: (770)-688-1642
Fax: (770)-510-4445

-----Original Message-----
From: devel [mailto:devel-bounces at rtems.org] On Behalf Of Sebastian Huber
Sent: Friday, June 30, 2017 1:15 AM
To: devel at rtems.org
Subject: Re: LIBBSD

On 29/06/17 20:02, Kirspel, Kevin wrote:

> For those who run a RTEMS 4.12 single processor application with 
> LIBBSD, what percentage of time does your application spend in the 
> timer server task?  My NXP LPC3250 application spends about 13% of the 
> processor time processing the timer server.  Most of that time is 
> spent processing LIBBSD's kernel callouts.  I am wondering if there is 
> an advantage to only call the FreeBSD's callout_process() function 
> when we know a callout needs to be processed.  This would reduce the 
> number of RTEMS timer fires (which currently fire every tick).

Normally, the timer server should be in the range of 0.x% of CPU time. 
If you have 13%, then you have a lot of timeout processing. What is the reason for this?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

_______________________________________________
devel mailing list
devel at rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwIF-g&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=wi6q2gTnD-FidfbEqMhvlESvqYn-Fmg-tXnNg62S3BY&s=8pSzson7fylkfTRzYKIMlQnFgvwpY8lpExFHqEEapbc&e=
_______________________________________________
devel mailing list
devel at rtems.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwIFAw&c=2do6VJGs3LvEOe4OFFM1bA&r=HDiJ93ANMEQ32G5JGdpyUxbdebuwKHBbeiHMr3RbR74&m=RMQjCIXGYJE0sLPFXFT_ff4hxd0Xv4XwddHMeiJ22Dg&s=3xFmeotPlm109pDOuYPFrRHA4IDShM96NNS3CGwextE&e=