Andrew Morton wrote:
> Spotted on lkml...
>
>
>
> Begin forwarded message:
>
> Date: Mon, 26 May 2003 17:09:34 -0400
> From: Richard C Bilson <[email protected]>
> To: [email protected]
> Subject: setitimer 1 usec fails
>
>
> In trying the latest development kernel, I've noticed that calling
> setitimer with a 1 usec delay (the shortest possible delay) results in
> the timer never going off. 2 usec is ok but 1 is not, so I suspect
> that somehow things are being rounded off incorrectly. The attached
> program demonstrates the problem on 2.5.69, but runs correctly on a
> 2.4.20 kernel.
>
> I have only had the opportunity to try this on a single architecture
> (ia64), so if anyone can convince me that it's a platform-specific
> problem I'll be happy to take my gripe to the ia64 list. I've tried to
> figure out how the usecs are converted to jiffies, but the code is
> sufficiently convoluted that I thought I'd throw it out in the hope of
> finding someone who understands the situation a little better.
I am not sure, but this could be related to the HZ=1024 problem Eric
Piel and I are trying to run down. This is a rather bad choice for HZ
due to round off error on the conversions to usec. We THINK the
right thing to do is to convert to nsec (this is for TICK_NSEC()),
directly rather than first to usec and then to nsec.
The additional problem is that the ntp code attempts to correct for
the roundoff error which makes for an always correcting wall clock
(even without turning on ntp). What is needed and what I am trying to
find time to do, is to convert the ntp code to work from the nsec
resolution of xtime rather from the old usec resolution. Problem is I
don't know the ntp code so it is a bit of a learning curve.
Help here is welcome!!
As a test, you might try your test with HZ=1000 (a number I recommend
for ia64, if at all possible).
-g
>
> - Richard
>
> // When run, this program should print "handled alarm" from within the
> // signal handler, and "out of sigsuspend" right after. It works on
> // 2.4.20 or if MY_TIMER_USEC is >= 2, but not on 2.5.69 with
> // MY_TIMER_USEC = 1.
>
> #define MY_TIMER_USEC 1
>
> #include <stdio.h>
> #include <unistd.h>
> #include <signal.h>
> #include <sys/time.h>
>
> void
> alarm_handler( int x )
> {
> printf( "handled alarm\n" );
> return;
> }
>
> int
> main()
> {
> struct itimerval it = { { 0, 0 }, { 0, MY_TIMER_USEC } };
> sigset_t mask;
> struct sigaction act;
>
> act.sa_handler = alarm_handler;
> act.sa_flags = 0;
> sigemptyset( &act.sa_mask );
> if( sigaction(SIGALRM, &act, 0) ) {
> perror( "sigaction" );
> exit( 1 );
> }
>
> if( setitimer(ITIMER_REAL, &it, 0) ) {
> perror( "setitimer" );
> exit( 1 );
> }
>
> sigemptyset( &mask );
> sigsuspend( &mask );
>
> printf( "out of sigsuspend\n" );
> return 0;
> }
>
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
>>>>> On Mon, 26 May 2003 15:00:53 -0700, george anzinger <[email protected]> said:
George> As a test, you might try your test with HZ=1000 (a number I
George> recommend for ia64, if at all possible).
I suspect you might have a slightly biased view on this. ;-) Yes,
HZ=1000 makes some problems easier to convert ticks to real time, but
slower to convert real time to ticks.
Besides, the Linux kernel MUST work with (fairly) arbitrary HZ values,
because some platforms just don't have much of a choice (e.g., Alpha
is pretty much forced to 1024Hz).
But, yes, on ia64 we can choose HZ to our liking. If someone presents
evidence that shows a real benefit for a value other than 1024, I'm
certainly willing to listen.
--david
David Mosberger wrote:
>>>>>>On Mon, 26 May 2003 15:00:53 -0700, george anzinger <[email protected]> said:
>
>
> George> As a test, you might try your test with HZ=1000 (a number I
> George> recommend for ia64, if at all possible).
>
> I suspect you might have a slightly biased view on this. ;-) Yes,
> HZ=1000 makes some problems easier to convert ticks to real time, but
> slower to convert real time to ticks.
Ulrich has written something on this. Maybe he could comment :)
-g
>
> Besides, the Linux kernel MUST work with (fairly) arbitrary HZ values,
> because some platforms just don't have much of a choice (e.g., Alpha
> is pretty much forced to 1024Hz).
>
> But, yes, on ia64 we can choose HZ to our liking. If someone presents
> evidence that shows a real benefit for a value other than 1024, I'm
> certainly willing to listen.
>
> --david
>
>
--
George Anzinger [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml