All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@us.ibm.com>
To: Darren Hart <darren@dvhart.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	blainey@ca.ibm.com, Martin J Bligh <mbligh@aracnet.com>,
	nacc@us.ibm.com, johnstul@us.ibm.com, fultonm@ca.ibm.com
Subject: Re: nanosleep resolution, jiffies vs microseconds
Date: Wed, 8 Dec 2004 09:14:20 -0800	[thread overview]
Message-ID: <20041208171420.GD1270@us.ibm.com> (raw)
In-Reply-To: <1102524468.16986.30.camel@farah.beaverton.ibm.com>

Hello, Darren,

Thank you very much for getting to the bottom of this!

This is mostly an issue when sleeping for small numbers of ticks,
so if HZ was 10000, a nanosleep(1000000) would get bumped by
a couple hundred microseconds rather than the current milliseconds,
right?

Further, if one were to do nanosleep(900000) given HZ of 1024,
the expected sleep time would be 2 milliseconds, right?

						Thanx, Paul

On Wed, Dec 08, 2004 at 08:47:48AM -0800, Darren Hart wrote:
> I am looking at trying to improve the latency of nanosleep for short
> sleep times (~1ms).  After reading Martin Schwidefsky's post for cputime
> on s390 (Message-ID:
> <20041111171439.GA4900@mschwid3.boeblingen.de.ibm.com>), it seems to me
> that we may be able to accomplish this by storing the expire time in
> microseconds rather than jiffies.  Here is an example for context:
> 
> Say we want to sleep for 1ms on i386, we call nanosleep(1000000).
> Unfortunately on i386 a jiffy is slightly less than 1ms (as one might
> expect with HZ = 1000).  So when sys_nanosleep calls
> timespec_to_jiffies, it returns 2.  Now to allow for the corner case
> when my 1ms sleep request gets called at the very tail end of a clock
> period (see ascii diagram below), nanosleep adds 1 to that and calls
> schedule_timeout with 3.  So a 1 ms sleep correctly turns into 3
> jiffies.
> 
> If we were to store the expire value in microseconds, this corner case
> would still exist and still span two full tick periods.  However, the
> large majority of the time, nanosleep(1000000) could pause for only 2
> jiffies, instead of 3.  Before I dug to deep into the relevant code I
> wanted to hear some opinions on this approach.
> 
> 
> Worst case scenario for a 1ms sleep:
> 
> TICK @ 1000000000 ns ------------------------   (X jiffies)
> 
> 
>     nanosleep(1000000) // this can't correctly wake until 1001999849
> TICK @ 1000999849 ns ------------------------   (X jiffies + 1)
> 
> 
> 
> TICK @ 1001999698 ns ------------------------   (X jiffies + 2)
>     at 1001999849 nanosleep call can wake up
>     (but since this is after X jiffies + 2, we can't actually wake
>      until X jiffies + 3)
> 
> TICK @ 1002999547 ns ------------------------   (X jiffies + 3)
>     wake from nanosleep
> 
> 
> Thanks,
> 
> -- 
> Darren Hart <darren@dvhart.com>
> 
> 
> 

  parent reply	other threads:[~2004-12-08 17:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-08 16:47 nanosleep resolution, jiffies vs microseconds Darren Hart
2004-12-08 17:05 ` Mike Kravetz
2004-12-08 17:49   ` Paul E. McKenney
2004-12-08 17:14 ` Paul E. McKenney [this message]
2004-12-08 18:30   ` Darren Hart
2004-12-09 10:21 ` Jan Engelhardt

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=20041208171420.GD1270@us.ibm.com \
    --to=paulmck@us.ibm.com \
    --cc=blainey@ca.ibm.com \
    --cc=darren@dvhart.com \
    --cc=fultonm@ca.ibm.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=nacc@us.ibm.com \
    /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.