From: David Woodhouse <dwmw2@infradead.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
arjan@infradead.org
Subject: Re: [RFC] schedule_timeout_range()
Date: Tue, 22 Jul 2008 00:12:02 -0400 [thread overview]
Message-ID: <1216699922.18980.66.camel@shinybook.infradead.org> (raw)
In-Reply-To: <200807221356.29892.nickpiggin@yahoo.com.au>
On Tue, 2008-07-22 at 13:56 +1000, Nick Piggin wrote:
> Rather than specific "deadline" values (which we can't guarantee anyway),
> or vague "can defer" values,
We already _have_ those vague 'can defer' timers. They'll get run the
next time the CPU happens to be awake after they expire.
> I would prefer just a small selection of maybe orders of magnitude
> flags, maybe SECONDS, MILLISECONDS, MICROSECONDS which gives an amount
> of delay the kernel might add to the timer.
As far as I can tell, any implementation of that ends up being converted
into what we have at the moment -- a deferrable timer which gets run
some time after it expires, and a timer which would actually _wake_ a
sleeping CPU. You have to create a value for that final timer anyway, so
why not just let the in-kernel caller provide it?
There's no point in trying to coalesce the 'final' timeouts; if just one
of them wakes the CPU and we're in the range for any other 'range
timers', those others will happy immediately anyway.
We did ponder the idea of a per-process setting which affects userspace
delays like nanosleep/poll/select, and introduces a variable extra delay
if the CPU is actually sleeping. So we can reduce the number of CPU
wakeup events for thosee userspace apps which aren't timing-sensitive.
We were also thinking of extending nanosleep/ppoll/pselect also to take
a 'range', for those cases where the process-wide setting needs to be
overridden. The prctl is a simple solution which doesn't involve
modifying large chunks of userspace to use new system calls, but it's
not a panacea -- in some places, an app might _want_ a prompt wakeup.
For kernel timers, though, I think it's better to let the caller set a
non-deferrable timer at a specific time. Although you're right that
'deadline' is probably a bad name for it.
How about 'start' and 'end'? Or 'early' and 'late'? I really don't care
too much what it's called.
--
dwmw2
next prev parent reply other threads:[~2008-07-22 4:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-22 3:02 [RFC] Imprecise timers David Woodhouse
2008-07-22 3:05 ` [RFC] schedule_timeout_range() David Woodhouse
2008-07-22 3:56 ` Nick Piggin
2008-07-22 4:12 ` David Woodhouse [this message]
2008-07-22 4:26 ` Arjan van de Ven
2008-07-22 4:34 ` David Woodhouse
2008-07-22 4:33 ` Nick Piggin
2008-07-22 4:45 ` David Woodhouse
2008-07-22 4:50 ` Nick Piggin
2008-07-22 4:58 ` David Woodhouse
2008-07-22 5:35 ` Jan Engelhardt
2008-07-22 4:33 ` Arjan van de Ven
2008-07-22 7:19 ` [RFC] Imprecise timers Rene Herman
2008-07-22 12:54 ` Arjan van de Ven
2008-07-22 14:04 ` Rene Herman
2008-07-29 0:36 ` Pallipadi, Venkatesh
2008-08-09 12:54 ` Pavel Machek
2008-08-11 17:35 ` Venki Pallipadi
2008-08-12 12:00 ` Pavel Machek
2008-08-12 18:11 ` Venki Pallipadi
2008-08-12 21:55 ` Alan Cox
2008-08-12 21:58 ` Pavel Machek
[not found] <aSgqr-EJ-15@gated-at.bofh.it>
[not found] ` <aShcU-3uj-11@gated-at.bofh.it>
[not found] ` <aShw5-4ai-9@gated-at.bofh.it>
[not found] ` <aShPs-4IY-1@gated-at.bofh.it>
2008-07-23 11:52 ` [RFC] schedule_timeout_range() Bodo Eggert
2008-07-24 0:53 ` Nick Piggin
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=1216699922.18980.66.camel@shinybook.infradead.org \
--to=dwmw2@infradead.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=tglx@linutronix.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;
as well as URLs for NNTP newsgroup(s).