lkml.org 
[lkml]   [2005]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Subject[PATCH] Bad rounding in timeval_to_jiffies [was: Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)]
From
Date
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@accessline.com 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-04-21 05:02    [W:0.242 / U:2.944 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site