public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Piel <Eric.Piel@Bull.Net>
To: davidm@hpl.hp.com
Cc: linux-ia64@linuxia64.org, linux-kernel@vger.kernel.org,
	Vitezslav Samel <samel@mail.cz>
Subject: Re: [BUG] nanosleep() granularity bumps up in 2.5.64 (was: [PATCH]  settimeofday() not synchronised with gettimeofday())
Date: Fri, 14 Mar 2003 15:34:36 +0100	[thread overview]
Message-ID: <3E71E87C.10CBC8F7@Bull.Net> (raw)
In-Reply-To: 15984.58358.499539.299000@napali.hpl.hp.com

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

       reply	other threads:[~2003-03-14 14:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3E70B797.DFC260B@Bull.Net>
     [not found] ` <15984.58358.499539.299000@napali.hpl.hp.com>
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() not synchronised with gettimeofday()) Matthew Wilcox
2003-03-17  7:45       ` Vitezslav Samel
2003-03-17 13:55         ` [BUG] nanosleep() granularity bumps up in 2.5.64 Tim Schmielau
2003-03-17 19:42           ` [BUG & WORKAROUND] " Tim Schmielau
2003-03-18  9:05             ` [PATCH] fix nanosleep() granularity bumps Tim Schmielau
2003-03-24 12:06               ` Finn Arne Gangstad
2003-03-24 12:10                 ` Tim Schmielau
2003-03-14 19:29     ` [Linux-ia64] Re: [BUG] nanosleep() granularity bumps up in 2.5.64 (was: [PATCH] settimeofday() not synchronised with gettimeofday()) David Mosberger

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=3E71E87C.10CBC8F7@Bull.Net \
    --to=eric.piel@bull.net \
    --cc=davidm@hpl.hp.com \
    --cc=linux-ia64@linuxia64.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=samel@mail.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox