[PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timerbehavior in 2.6 vs 2.4 (1 extra tick)]

[Steven Rostedt]

I looked into the problem that jdavis had and found that the conversion
of the timeval_to_jiffies was off by one. 

To convert tv.tv_sec = 0, tv.tv_usec = 10000 to jiffies, you come up
with an answer of 11 (assuming 1000 HZ).  

Here's the patch:

--- ./include/linux/jiffies.h.orig	2005-04-20 22:30:34.000000000 -0400
+++ ./include/linux/jiffies.h	2005-04-20 22:39:42.000000000 -0400
@@ -231,7 +231,7 @@
  * in jiffies (albit scaled), it is nothing but the bits we will shift
  * off.
  */
-#define USEC_ROUND (u64)(((u64)1 << USEC_JIFFIE_SC) - 1)
+#define USEC_ROUND (u64)(((u64)1 << (USEC_JIFFIE_SC - 1)))
 /*
  * The maximum jiffie value is (MAX_INT >> 1).  Here we translate that
  * into seconds.  The 64-bit case will overflow if we are not careful,


I wrote a user program that copies all of the jiffies.h and shows the
output of the conversion.  Without this patch you get:

usec=10000  jiffies = 11
usec=10010  jiffies = 11
usec=10020  jiffies = 11
   .
   .
   .
usec=10980  jiffies = 11
usec=10990  jiffies = 11
usec=11000  jiffies = 12


With the patch, you get:

usec=10000  jiffies = 10
usec=10010  jiffies = 10
usec=10020  jiffies = 10
   .
   .
   .
usec=10480  jiffies = 10
usec=10490  jiffies = 10
usec=10500  jiffies = 11
usec=10510  jiffies = 11
   .
   .
   .
usec=10990  jiffies = 11
usec=11000  jiffies = 11

Which I believe is the more desired result.

I've kept jdavis original email to show where this was discovered.

-- Steve



On Fri, 2005-04-08 at 10:39 -0700, jdavis@xxxxxxxxxxxxxx wrote:
> 
> Hello, 
> 
> I've created a pretty straight forward timer using setitimer, and noticed
> some odd differences between 2.4 and 2.6, I wonder if I could get a
> clarification if this is the way it should work, or if I should continue to
> try to "fix" it.
> 
> I create a RealTime Thread( SCHED_FIFO, maxPriority-1 ) (also tried
> SCHED_RR) ...
> 
> that creates a timer ...setitimer( ITIMER_REAL, SIGALRM) with a 10 milli
> period. (I've also tried timer_create with CLOCK_REALTIME and SIGRTMIN)
> 
> and then the thread does a sem_wait() on a semaphore. 
> 
> the signal handler does a sem_post() .
> 
> 
> on 2.4.X the (idle) worst case latency is ~40 microseconds, 
> on 2.6.X the (idle) latency is about the same plus 1 tick of the scheduler
> ~1000 micro seconds... Always.. Every time.
> So to work around this on 2.6 I simply subtract 1 millisecond from my timer
> as a fudge factor and everything works as expected.
> 
> I've tried compiling various kernels (2.6.9, 2.6.11) with kernel pre-empting
> on, etc..
> 
> Is this the correct behavior? If so I'm curious who is using up the extra
> Tick?
> Does the asynch signal handler use up the whole tick even though it only has
> to sem_post()?
> 
> I am not subscribed to the list, so I would appreciate a CC.
> Thanks,
> -JD
> -

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/