Actually the tests should detect low res and adapt
reasonably well. The one problem(?)is that the
clock_nanosleep test finds the kernel timing bug introduced
by not pushing the wall clock 1/HZ on a tick. (The current
2.5 kernel actually pushes time a bit more than this
introducing a difference in the rate of time passing between
the wall clock an the jiffies. This causes timers to expire
early which is a big NO-NO, standard wise.)
This is most easily seen by doing:
time sleep 60
and noticing that it completes in less than 60 seconds, even
with the scheduling overhead.
>
> | -------
> | This patch supplies the core changes to implement high
> | resolution timers. Mostly it changes the timer list from
> | the multi stage hash (or cascade) list to a single stage
> | hash list. This change makes it easy to configure the list
> | size for those who are concerned with performance. It also
> | eliminates the "time out" for the cascade operation every
> | 512 jiffies, thus eliminating possibly long preemption
> | times. On input from Stephen Hemminger<shemminger@osdl.org>
> | the configuration of the timer list size is no longer
> | presented as a configure option. The code can still be
> | change (one line) to use larger or smaller lists.
> |
> | With this patch applied, the system should boot and run much
> | as it does prior to the patch. This patch depends on the
> | POSIX clocks & timers patch in that it assumes the changes
> | that patch made to timer.c to remove timer_t. This
> | dependency can be removed if needed.
>
> Couple of questions, please:
>
> 1. With HIGH_RES_TIMERS enabled, are all timers high-res timers,
> or does the API allow for some non-high-res timers (regular/normal)
> and some high-res-timers?
Actually you are asking a couple of questions here. First,
the API (POSIX clocks & timers) is extended in the high res
patch to add two new clocks:
CLOCK_REALTIME_HR
CLOCK_MONOTONIC_HR
Only calls using these clocks will generate the high-res
overhead (usually an interrupt is required that is somewhere
between two 1/HZ interrupts).
On the other hand, the timers list handling code was
expanded to handle sub jiffie values (but only the above API
can set these values) so there is a small (very small)
addition in timer handling to at least test that the sub
jiffie is zero.
Normal timers, i.e. setitimer, select, time_schedule, etc.
all use the normal low res timers so nothing changes here.
>
> 2. With HIGH_RES_TIMERS enabled and no apps trying to use high-res
> timers, should I be able to detect any additional system overhead
> due to the HIGH_RES_TIMERS code?
You would need a very sensitive tool to detect any
additional overhead. Still, as I mentioned above, there is
some.
>
> Thanks,
And thank you for the bug report.
-g
> --
> ~Randy
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 2.5.54-bk1 + POSIX/HRT patches, with HIGH_RES_TIMERS=n:
>
> kernel BUG at include/asm/spinlock.h:123!
> invalid operand: 0000
> CPU: 1
> EIP: 0060:[<c0130260>] Not tainted
> EFLAGS: 00010086
> EIP is at good_timespec+0x80/0x180
> eax: 0000000e ebx: ee5c471c ecx: f63d7100 edx: c03e2dec
> esi: 00000000 edi: ed50df9c ebp: ed50df8c esp: ed50df78
> ds: 007b es: 007b ss: 0068
> Process timer_test (pid: 1970, threadinfo=ed50c000 task=f5b85800)
> Stack: c0369bc0 c0130244 ed50c000 ed50df9c 00000000 ed50dfbc c01308d6 00000000
> ed50df9c 00000082 c0150e73 f7193ce4 40016000 00000032 ed50c000 4001526c
> 00000000 bfff9778 c0109537 00000000 00000000 bfff90a8 4001526c 00000000
> Call Trace:
> [<c0130244>] good_timespec+0x64/0x180
> [<c01308d6>] sys_timer_settime+0x16/0x180
> [<c0150e73>] sys_read+0x33/0x40
> [<c0109537>] system_call+0x7/0xb
>
> Code: 0f 0b 7b 00 64 98 36 c0 59 58 8d b6 00 00 00 00 f0 fe 4b 08
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 2.5.54-bk1 + POSIX/HRT patches, with HIGH_RES_TIMERS=y:
>
> kernel BUG at include/asm/spinlock.h:123!
> invalid operand: 0000
> CPU: 0
> EIP: 0060:[<c01307a0>] Not tainted
> EFLAGS: 00010086
> EIP is at good_timespec+0x80/0x180
> eax: 0000000e ebx: f68c589c ecx: f6f96300 edx: c03e3aec
> esi: 87000007 edi: f6919ed8 ebp: f6919ec8 esp: f6919eb4
> ds: 007b es: 007b ss: 0068
> Process 2timer_test (pid: 1940, threadinfo=f6918000 task=f6bc6b80)
> Stack: c036a860 c0130784 00000023 f6919f30 00000001 f6919ee4 c01300b8 87000007
> f6919ed8 00000086 00000023 f6919f30 f6919efc c0127117 f6919f30 f6919f30
> f6bc7130 f6918000 f6919f1c c012829a f6bc7130 f6919f30 f6bc7130 f6919fc4
> Call Trace:
> [<c0130784>] good_timespec+0x64/0x180
> [<c01300b8>] schedule_next_timer+0x18/0x50
> [<c0127117>] __dequeue_signal+0x87/0xa0
> [<c012829a>] notify_parent+0x7a/0x290
> [<c01092cd>] handle_signal+0x5d/0xd0
> [<c0222e5f>] copy_to_user+0x2f/0x40
> [<c01285ea>] do_no_restart_syscall+0x10a/0x240
> [<c0109582>] work_resched+0x13/0x15
>
> Code: 0f 0b 7b 00 04 a5 36 c0 59 58 8d b6 00 00 00 00 f0 fe 4b 08
>
> ###
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/