* [BUG] nanosleep() granularity bumps up in 2.5.64
@ 2003-03-14 8:30 Vitezslav Samel
0 siblings, 0 replies; 2+ messages in thread
From: Vitezslav Samel @ 2003-03-14 8:30 UTC (permalink / raw)
To: linux-kernel
Hi!
When playing with select() timeout values I found that granularity
of nanosleep() in 2.5.64 kernel bumps to 256 msec. Trying to get finer
granularity it ends up sleeping to the next multiple of 256 msec
(only for values > 256 msec): see this (for three last kernels) (measured with
attached program):
2.5.62 2.5.63 2.5.64
------ ------ ------
nanosleep(0.000): delay = 0.000 s 0.001 s 0.000 s
nanosleep(0.050): delay = 0.050 s 0.049 s 0.049 s
nanosleep(0.100): delay = 0.100 s 0.099 s 0.099 s
nanosleep(0.150): delay = 0.150 s 0.149 s 0.149 s
nanosleep(0.200): delay = 0.200 s 0.199 s 0.199 s
nanosleep(0.250): delay = 0.250 s 0.249 s 0.249 s
nanosleep(0.300): delay = 0.300 s 0.299 s 0.511 s
nanosleep(0.350): delay = 0.350 s 0.349 s 0.512 s
nanosleep(0.400): delay = 0.400 s 0.399 s 0.511 s
nanosleep(0.450): delay = 0.450 s 0.449 s 0.512 s
nanosleep(0.500): delay = 0.500 s 0.499 s 0.511 s
nanosleep(0.550): delay = 0.550 s 0.549 s 0.767 s
nanosleep(0.600): delay = 0.600 s 0.599 s 0.767 s
nanosleep(0.650): delay = 0.650 s 0.649 s 0.767 s
nanosleep(0.700): delay = 0.700 s 0.699 s 0.767 s
nanosleep(0.750): delay = 0.750 s 0.749 s 0.767 s
nanosleep(0.800): delay = 0.800 s 0.799 s 1.023 s
nanosleep(0.850): delay = 0.850 s 0.849 s 1.023 s
nanosleep(0.900): delay = 0.900 s 0.899 s 1.023 s
nanosleep(0.950): delay = 0.950 s 0.949 s 1.023 s
nanosleep(1.000): delay = 1.000 s 0.999 s 1.023 s
nanosleep(1.050): delay = 1.050 s 1.049 s 1.279 s
nanosleep(1.100): delay = 1.100 s 1.099 s 1.279 s
nanosleep(1.150): delay = 1.150 s 1.149 s 1.279 s
nanosleep(1.200): delay = 1.200 s 1.199 s 1.279 s
nanosleep(1.250): delay = 1.250 s 1.249 s 1.279 s
nanosleep(1.300): delay = 1.300 s 1.299 s 1.535 s
nanosleep(1.350): delay = 1.350 s 1.349 s 1.535 s
nanosleep(1.400): delay = 1.400 s 1.399 s 1.535 s
nanosleep(1.450): delay = 1.450 s 1.449 s 1.535 s
nanosleep(1.500): delay = 1.500 s 1.499 s 1.535 s
nanosleep(1.550): delay = 1.550 s 1.549 s 1.791 s
nanosleep(1.600): delay = 1.600 s 1.599 s 1.791 s
nanosleep(1.650): delay = 1.650 s 1.649 s 1.791 s
nanosleep(1.700): delay = 1.700 s 1.699 s 1.791 s
nanosleep(1.750): delay = 1.750 s 1.749 s 1.791 s
nanosleep(1.800): delay = 1.800 s 1.799 s 2.047 s
nanosleep(1.850): delay = 1.850 s 1.849 s 2.047 s
nanosleep(1.900): delay = 1.900 s 1.899 s 2.047 s
nanosleep(1.950): delay = 1.950 s 1.949 s 2.047 s
nanosleep(2.000): delay = 2.000 s 1.999 s 2.047 s
....
and so on.
In 2.5.63 there is a conversion to POSIX timers, but that change is O.K.
In the 2.5.64 changelog I didn't found any eye-hitting change.
Cheers,
Vita
------------------------------------------------------------------
#include <stdio.h>
#include <time.h>
#include <sys/time.h>
#include <errno.h>
int main (void) {
struct timespec req, rem;
struct timeval old, new;
long tim;
long delay;
int i;
gettimeofday(&old, NULL);
for (delay = 0; delay <= 2000000000L; delay += 50000000L) {
rem.tv_sec = 0;
rem.tv_nsec = 0;
req.tv_sec = delay / 1000000000L;
req.tv_nsec = delay % 1000000000L;
for (i = 0; i < 2; i++) { /* get only the second measured value */
int ret;
gettimeofday(&old, NULL);
ret = nanosleep(&req, &rem);
gettimeofday(&new, NULL);
tim = (new.tv_sec * 1000000 + new.tv_usec) - (old.tv_sec * 1000000 + old.tv_usec);
if (ret == -1) {
if (errno == EINTR) {
printf("EINTR\n");
i--;
} else {
perror("nanosleep()");
exit(1);
}
}
}
printf("nanosleep(%ld.%03ld): delay = %ld.%03ld s\n", req.tv_sec, req.tv_nsec / 1000000, tim / 1000000, (tim % 1000000) / 1000);
fflush(stdout);
}
return 0;
}
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [Linux-ia64] Re: [BUG] nanosleep() granularity bumps up in 2.5.64 (was: [PATCH] settimeofday() not synchronised with gettimeofday())
@ 2003-03-17 7:45 Vitezslav Samel
2003-03-17 13:55 ` [BUG] nanosleep() granularity bumps up in 2.5.64 Tim Schmielau
0 siblings, 1 reply; 2+ messages in thread
From: Vitezslav Samel @ 2003-03-17 7:45 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: Eric Piel, davidm, linux-ia64, linux-kernel
On Fri, Mar 14, 2003 at 02:48:59PM +0000, Matthew Wilcox wrote:
> On Fri, Mar 14, 2003 at 03:34:36PM +0100, Eric Piel wrote:
> > I think lines like that from patch-2.5.64 are very suspicious to be
> > related to the bug:
> > + base->timer_jiffies = INITIAL_JIFFIES;
> > + base->tv1.index = INITIAL_JIFFIES & TVR_MASK;
> > + base->tv2.index = (INITIAL_JIFFIES >> TVR_BITS) & TVN_MASK;
> > + base->tv3.index = (INITIAL_JIFFIES >> (TVR_BITS+TVN_BITS)) & TVN_MASK;
> > + base->tv4.index = (INITIAL_JIFFIES >> (TVR_BITS+2*TVN_BITS)) &
> > TVN_MASK;
> > + base->tv5.index = (INITIAL_JIFFIES >> (TVR_BITS+3*TVN_BITS)) &
> > TVN_MASK;
>
> No, I don't think so. Those lines are for starting `jiffies' at a very
> high number so we spot jiffie-wrap bugs early on.
The nanosleep() bug narrowed down to 2.5.63-bk2. That's version, the "initial
jiffies" patch went in. And yes, it's on i686 machine.
Cheers,
Vita
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [BUG] nanosleep() granularity bumps up in 2.5.64
2003-03-17 7:45 [Linux-ia64] Re: [BUG] nanosleep() granularity bumps up in 2.5.64 (was: [PATCH] settimeofday() not synchronised with gettimeofday()) Vitezslav Samel
@ 2003-03-17 13:55 ` Tim Schmielau
0 siblings, 0 replies; 2+ messages in thread
From: Tim Schmielau @ 2003-03-17 13:55 UTC (permalink / raw)
To: Vitezslav Samel; +Cc: Matthew Wilcox, Eric Piel, davidm, linux-ia64, lkml
On Mon, 17 Mar 2003, Vitezslav Samel wrote:
> On Fri, Mar 14, 2003 at 02:48:59PM +0000, Matthew Wilcox wrote:
> > On Fri, Mar 14, 2003 at 03:34:36PM +0100, Eric Piel wrote:
> > > I think lines like that from patch-2.5.64 are very suspicious to be
> > > related to the bug:
> > > + base->timer_jiffies = INITIAL_JIFFIES;
> > > + base->tv1.index = INITIAL_JIFFIES & TVR_MASK;
> > > + base->tv2.index = (INITIAL_JIFFIES >> TVR_BITS) & TVN_MASK;
> > > + base->tv3.index = (INITIAL_JIFFIES >> (TVR_BITS+TVN_BITS)) & TVN_MASK;
> > > + base->tv4.index = (INITIAL_JIFFIES >> (TVR_BITS+2*TVN_BITS)) &
> > > TVN_MASK;
> > > + base->tv5.index = (INITIAL_JIFFIES >> (TVR_BITS+3*TVN_BITS)) &
> > > TVN_MASK;
> >
> > No, I don't think so. Those lines are for starting `jiffies' at a very
> > high number so we spot jiffie-wrap bugs early on.
>
> The nanosleep() bug narrowed down to 2.5.63-bk2. That's version, the "initial
> jiffies" patch went in. And yes, it's on i686 machine.
You can easily check whether it's connected with this change by setting
INITIAL_JIFFIES to zero. This should exactly recover the previous
situation.
I.e., something like the following (untested, hand-crafted) patch:
--- linux-2.5.64/include/linux/time.h
+++ linux-2.5.64/include/linux/time.h
@@ -28,7 +28,7 @@
* Have the 32 bit jiffies value wrap 5 minutes after boot
* so jiffies wrap bugs show up earlier.
*/
- #define INITIAL_JIFFIES ((unsigned int) (-300*HZ))
+ #define INITIAL_JIFFIES 0
/*
* Change timeval to jiffies, trying to avoid the
Tim
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-03-17 13:45 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-14 8:30 [BUG] nanosleep() granularity bumps up in 2.5.64 Vitezslav Samel
2003-03-17 7:45 [Linux-ia64] Re: [BUG] nanosleep() granularity bumps up in 2.5.64 (was: [PATCH] settimeofday() not synchronised with gettimeofday()) Vitezslav Samel
2003-03-17 13:55 ` [BUG] nanosleep() granularity bumps up in 2.5.64 Tim Schmielau
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®