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-0001.bin>
More information about the users
mailing list