From: Eric Piel <Eric.Piel@Bull.Net>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] Re: [BUG] nanosleep() granularity bumps up in 2.5.64 (was: [PATCH]
Date: Fri, 14 Mar 2003 14:34:36 +0000 [thread overview]
Message-ID: <marc-linux-ia64-105590709806094@msgid-missing> (raw)
David Mosberger wrote:
> Are you running ntp?
Yes (I hadn't noticed it) but it was not connected to any server and
disabling it doesn't change the results.
>
> On 2.5:
>
> $ time sleep 16
> real 0m16.002s
> user 0m0.001s
> sys 0m0.002s
>
> $ time sleep 16.02
> real 0m25.189s
> user 0m0.000s
> sys 0m0.001s
>
> So clearly something very strange is going on. My suspicion is that
> the bug was introduced back when x86 switched from 100Hz to 1000Hz
> ticks, but that's just a guess. Eric, would you be
> able/willing/interested to look into this?
Sure, I aim at porting the high resolution timers but any annoying bug
related to the time can be interesting to remove.
Coincidently Vita has just reported a bug on the lkml which, after a
closer look, seems to be the same:
> 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
From what I understand their is a bug in the timers that causes a big
granularity. The case of Vita is a very good example. Also, after 16s it
seems the granuality (slowly?!) jumps from 1/64th s to 16s! :
sleep requested time obtained
14.000000000 14.006201744
15.000000000 15.006647110
16.000000000 16.007089615
17.000000000 18.742679596
18.000000000 32.014190674
19.000000000 32.014190674
20.000000000 32.014190674
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;
Any idea/sugestion/patch is welcomed. Whatever, I will try to fix this
as soon as I'm back from my week end :-)
Eric
next reply other threads:[~2003-03-14 14:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-14 14:34 Eric Piel [this message]
2003-03-14 14:48 ` [Linux-ia64] Re: [BUG] nanosleep() granularity bumps up in 2.5.64 (was: [PATCH] settimeofday() n Matthew Wilcox
2003-03-14 19:29 ` [Linux-ia64] Re: [BUG] nanosleep() granularity bumps up in 2.5.64 (was: [PATCH] David Mosberger
2003-03-17 7:45 ` [Linux-ia64] Re: [BUG] nanosleep() granularity bumps up in 2.5.64 (was: [PATCH] settimeofday() n Vitezslav Samel
2003-03-17 13:55 ` [Linux-ia64] Re: [BUG] nanosleep() granularity bumps up in 2.5.64 Tim Schmielau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-ia64-105590709806094@msgid-missing \
--to=eric.piel@bull.net \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.