RE: LIBBSD
I'm not sure but I'll look into it today. I'll need to quantify each callout handler's processing time to see which one is causing the problem. I know the USB and Ethernet stacks/drivers use callouts but maybe there is something else. Kevin Kirspel Electrical Engineer - Sr. Staff Idexx Roswell 235 Hembree Park Drive Roswell GA 30076 Tel: (770)-510- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber Sent: Friday, June 30, 2017 1:15 AM To: devel@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.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@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@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] c-user: Document EDF SMP
Close #3056. --- c-user/configuring_a_system.rst | 27 +++ c-user/scheduling_concepts.rst | 7 +++ 2 files changed, 34 insertions(+) diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst index 71c5c71..17c8a85 100644 --- a/c-user/configuring_a_system.rst +++ b/c-user/configuring_a_system.rst @@ -3795,6 +3795,33 @@ DESCRIPTION: NOTES: None. +.. COMMENT: === CONFIGURE_SCHEDULER_EDF_SMP === + +.. _Use Earliest Deadline First SMP Scheduler: + +Use Earliest Deadline First Scheduler +- +.. index:: CONFIGURE_SCHEDULER_EDF_SMP + +CONSTANT: +``CONFIGURE_SCHEDULER_EDF_SMP`` + +DATA TYPE: +Boolean feature macro. + +RANGE: +Defined or undefined. + +DEFAULT VALUE: +This is not defined by default. + +DESCRIPTION: +If defined, then the Earliest Deadline First (EDF) SMP Scheduler is +selected as the default scheduler. + +NOTES: +None. + .. COMMENT: === CONFIGURE_SCHEDULER_CBS === .. _Use Constant Bandwidth Server Scheduler: diff --git a/c-user/scheduling_concepts.rst b/c-user/scheduling_concepts.rst index cea863d..7a77a33 100644 --- a/c-user/scheduling_concepts.rst +++ b/c-user/scheduling_concepts.rst @@ -183,6 +183,13 @@ period, it has to be finished until the end of this period. The call of deadline. Moreover, the ``rtems_rate_monotonic_cancel`` and ``rtems_rate_monotonic_delete`` calls clear the deadlines assigned to the task. +Earliest Deadline First SMP Scheduler +- + +An EDF scheduler with SMP support. The processors managed by this scheduler +are allocated to the highest priority (earliest deadline) tasks which are ready +to execute. + Constant Bandwidth Server Scheduling (CBS) -- .. index:: constant bandwidth server scheduling -- 2.12.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Common practice of interrupt implementation in RTEMS
Hello all, what is the common practice of interrupt implementation in RTEMS? I wasn't able to find much information in RTEMS BSP manual. My platform RISC-V has vectored interrupts and exceptions. A cause of an exception or of an interrupt is always available in 'mcause' register. But for interrupts an address of a handlers' table can also be dynamically provided. So, what should I do in order to implement interrupt handlers? What is the consequence of steps when interrupt appears (save stack, make a routine...)? Also, what is a good example of a BSP which implements ISR in a proper way? -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
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- ext. 81642 Direct: (770)-688-1642 Fax: (770)-510-4445 -Original Message- From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Sebastian Huber Sent: Friday, June 30, 2017 1:15 AM To: devel@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.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@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@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Common practice of interrupt implementation in RTEMS
https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing https://docs.rtems.org/branches/master/bsp-howto.html#set-vector-install-an-interrupt-vector On Fri, Jun 30, 2017 at 10:49 AM, Denis Obrezkov wrote: > Hello all, > what is the common practice of interrupt implementation in RTEMS? > I wasn't able to find much information in RTEMS BSP manual. > > My platform RISC-V has vectored interrupts and exceptions. > A cause of an exception or of an interrupt is always available in 'mcause' > register. > But for interrupts an address of a handlers' table can also be dynamically > provided. > So, what should I do in order to implement interrupt handlers? > What is the consequence of steps when interrupt appears (save stack, make a > routine...)? > Also, what is a good example of a BSP which implements ISR in a proper way? > > -- > Regards, Denis Obrezkov > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Common practice of interrupt implementation in RTEMS
Could someone expand it a bit. For example, I can provide an interrupt table in my start.S file. So, when interrupts occurs, pc counter is set to the appropriate address in table entry. And we have several RTEMS interrupt handlers. And RTEMS handlers table. How do they relate to each other? 2017-06-30 20:48 GMT+02:00 Gedare Bloom : > https://docs.rtems.org/branches/master/cpu-supplement/port.html# > interrupt-processing > > https://docs.rtems.org/branches/master/bsp-howto. > html#set-vector-install-an-interrupt-vector > > > On Fri, Jun 30, 2017 at 10:49 AM, Denis Obrezkov > wrote: > > Hello all, > > what is the common practice of interrupt implementation in RTEMS? > > I wasn't able to find much information in RTEMS BSP manual. > > > > My platform RISC-V has vectored interrupts and exceptions. > > A cause of an exception or of an interrupt is always available in > 'mcause' > > register. > > But for interrupts an address of a handlers' table can also be > dynamically > > provided. > > So, what should I do in order to implement interrupt handlers? > > What is the consequence of steps when interrupt appears (save stack, > make a > > routine...)? > > Also, what is a good example of a BSP which implements ISR in a proper > way? > > > > -- > > Regards, Denis Obrezkov > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > -- Regards, Denis Obrezkov ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
