mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Arjan van de Ven <arjan@infradead.org>,
	linux-kernel@vger.kernel.org, mingo@elte.hu, tglx@tglx.de
Subject: Re: [PATCH 4/5] select: make select() use schedule_hrtimeout()
Date: Fri, 29 Aug 2008 10:26:02 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.1.10.0808291009450.3300@nehalem.linux-foundation.org> (raw)
In-Reply-To: <20080829171108.63e6dcd4@lxorguk.ukuu.org.uk>



On Fri, 29 Aug 2008, Alan Cox wrote:
>
> > "schedule_timeout()", there's a big difference between asking for two 
> > ticks and asking for two seconds. The latter should probably try to round 
> > to a nice timer tick basis for power reasons).
> 
> I disagree - that is fixing the problem in the wrong place. The timer
> structure needs an accuracy field of some form that the existing timer
> functions initialise to 0.

I do agree that we could do that too, but you miss one big issue: even if 
we were to add an accuracy field inside the kernel, there is no such field 
in the user interfaces.

We just pass timevals (and sometimes timespecs) around, and no, they don't 
have any way to specify accuracy.

Yeah, we could use the high bits in the usec/nsec words, but then older 
kernels would basically do random things, so that would be a horrible 
interface.

The other thing to do would be to just add totally new system calls with 
totally new interfaces, but (a) nobody would use them anyway and (b) it's 
simply not worth it.

So given that reality, and _if_ we want to support nice high-resolution 
sleeping by select/poll, the only reasonable thing to do is to estimate 
some kind of expected accuracy from the existing timeval/timespec.

And the only reasonable way to do that is to just look at the range. You 
can probably do something fairly trivial with

	/* Estimate expected accuracy in ns from a timeval */
	unsigned long estimate_accuracy(struct timeval *tv)
	{
		/*
		 * Tens of ms if we're looking at seconds, even
		 * more for 10s+ sleeping
		 */
		if (tv->tv_sec) {
			/* Tenths of seconds for long sleeps */
			if (tv->tv_sec > 10)
				return 100000000;
			/*
			 * Tens of ms for second-granularity sleeps. This,
			 * btw, is the historical Linux 100Hz timer range.
			 */
			return 10000000;
		}

		/* Single msecs if we're looking at milliseconds */
		if (tv->tv_usec > 1000)
			return 1000000;

		/* Aim for tenths of msecs otherwise */
		return 100000;
	}

and yes, it's just a heuristic, but it's probably not a horribly stupid 
one or a very unreasonable one. 

			Linus

  reply	other threads:[~2008-08-29 17:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-29 15:05 [patch 0/5] Nano/Microsecond resolution for select() and poll() Arjan van de Ven
2008-08-29 15:06 ` [PATCH 1/5] select: add a timespec version of the timeout to select/poll Arjan van de Ven
2008-08-30  2:10   ` Andrew Morton
2008-08-30  2:54     ` Linus Torvalds
2008-08-29 15:07 ` [PATCH 2/5] select: return accurate remainer in select() and ppoll() Arjan van de Ven
2008-08-29 15:07 ` [PATCH 3/5] select: introduce a schedule_hrtimeout() function Arjan van de Ven
2008-08-29 15:08 ` [PATCH 4/5] select: make select() use schedule_hrtimeout() Arjan van de Ven
2008-08-29 15:36   ` Arnd Bergmann
2008-08-29 15:59   ` Daniel Walker
2008-08-29 16:20   ` Linus Torvalds
2008-08-29 16:11     ` Alan Cox
2008-08-29 17:26       ` Linus Torvalds [this message]
2008-08-29 17:42         ` Arjan van de Ven
2008-08-29 18:18         ` Alan Cox
2008-08-29 18:46           ` Linus Torvalds
2008-08-29 18:33             ` Alan Cox
2008-08-30 15:25               ` Arjan van de Ven
2008-08-29 16:30     ` Arjan van de Ven
2008-08-29 15:08 ` [PATCH 5/5] select: make poll() use schedule_hrtimeout() as well Arjan van de Ven
2008-08-29 15:54 ` [patch 0/5] Nano/Microsecond resolution for select() and poll() Arnd Bergmann
2008-08-29 16:12   ` Arjan van de Ven
2008-08-29 22:15 ` Brian Wellington

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=alpine.LFD.1.10.0808291009450.3300@nehalem.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@tglx.de \
    /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

all inboxes | Powered by JetHome®