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:45:25 -0400 [thread overview]
Message-ID: <1216701925.18980.75.camel@shinybook.infradead.org> (raw)
In-Reply-To: <200807221433.32412.nickpiggin@yahoo.com.au>
On Tue, 2008-07-22 at 14:33 +1000, Nick Piggin wrote:
> The only thing I dislike about explicit times is that when a driver or
> someone doesn't _really_ know how much to specify. Do you say 10s, 100s?
This is true, but they certainly have a _better_ idea than we do. If the
individual callers can't even come up with an answer, how are we ever
going to come up with a generic policy that does the right thing?
I really don't think that applying this kind of policy in generic code
is useful -- I'd like the callers to provide numbers even if they _do_
pull it out of their wossname.
The number they provide is the _maximum_ amount of time they should be
prepared to wait (let's assume for a moment that they stayed sober and
remembered Linux isn't a real-time kernel, so all guarantees are taken
with a pinch of salt. Let's not get bogged down in nomenclature).
In practice, they'll almost always get called before that maximum time
expires -- that's the whole _point_, of course. But we can't _invent_
that maximum in generic code; that's really up to the caller.
> Some upper bound would be nice, which basically would not have to ever
> fire by itself unless there is some CPU activity (so you don't have to
> set two timers as a bonus). After that, I wonder, perhaps some "maximum
> power savings value but not completely deferred"? Say give it a max of
> 30s? Or perhaps even that is not future-proof enough if we one day want
> to suspend most of the system between external IOs?
I _really_ don't think we want to go there. Let the caller set a maximum
amount of time they're prepared to wait, and that's it.
--
dwmw2
next prev parent reply other threads:[~2008-07-22 4:45 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
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 [this message]
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=1216701925.18980.75.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).