Any Issues Preventing 4.9.1?

Michael South msouth at msouth.org
Sat Nov 22 01:29:02 UTC 2008


OK, I've got it done. Instead of using HPET chips (I don't have ready
access to such a motherboard), I used the TSC register available on
Pentium-class CPUs. There are some pluses and minuses to that; high
precision, _if_ the BIOS doesn't alter the clock frequency for thermal
or power saving reasons.

Anyway, it's all attached for your perusal.

Summary of results:
Six varieties of code tested:

1) Unmodified ckinit.c

2) Un-modified ckinit.c, configured with
USE_TICKS_FOR_CPU_USAGE_STATISTICS=1

3) Just commented out I/O

4) Re-worked ckinit.c, with new switch CLOCK_DRIVER_USE_TSC = 1.
   It uses the TSC register on Pentium-class processors.

5) Re-worked ckinit.c, with new switch CLOCK_DRIVER_USE_8529 = 1.
   Equivalent to unmodified ckinit.c.

6) Re-worked ckinit.c, with neither ..._USE_TSC nor ..._USE_8529
   defined. Equivalent to (3).

Test box is a 500 MHz AMD K6-2.


      Context switches       nSec per switch
      per tick (1 KHz)

(1)         153                    6,525
(2)       1,582                      632
(3)       1,025                      976
(4)         939                    1,065
(5)         153                    6,524
(6)       1,117                      895


On Wed, 2008-11-19 at 08:42 -0600, Joel Sherrill wrote:
> Michael South wrote:
> > Getting really bad context switch times on pc386 when
> > RTEMS_ENABLE_NANOSECOND_CPU_USAGE_STATISTICS is enabled. (Something
> > like a factor of ten on one of my desktops). I posted a discussion note
> > on the 4.9.0 release Wiki page.
> >   
> 
> I just saw the talk page this morning.   Can you try a few
> things and let's see where that takes us.
> 
> + Send me your test program so I can check it on other
>     targets.
> + Temporarily change bsp_clock_nanoseconds_since_last_tick()
>    in /c/src/lib/libbsp/i386/pc386/clock/ckinit.c to return 0 and
>    not touch the hardware.  Rerun and report results.
> + If above shows problem, provide alternative code that uses
>     the method you mention in the Wiki Talk page.
> + If we can't dynamically figure out if the alternative method
>    works, then we can make it a BSP configure time option
>    like using COM1 as console (see configure.ac in the pc386
>    directory).  If you can provide the code, I can fix the configure.ac
>    if this turns out to be needed.
> 
> I have had concerns that the timespec math is expensive but
> never thought that slow clock hardware would be an issue.
>   
> > --
> > Michael South msouth at msouth.org
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
> >   
> 
> 
-- 
---
Michael South
msouth at msouth.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clockpatch.tgz
Type: application/x-compressed-tar
Size: 7275 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20081121/0484a60e/attachment.bin>


More information about the users mailing list