[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200807241053.49304.nickpiggin@yahoo.com.au>
Date: Thu, 24 Jul 2008 10:53:49 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: 7eggert@....de
Cc: linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, arjan@...radead.org,
David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RFC] schedule_timeout_range()
On Wednesday 23 July 2008 21:52, Bodo Eggert wrote:
> Nick Piggin <nickpiggin@...oo.com.au> 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?
> > It shouldn't be arbitrary, but we should have a few constants I think.
>
> You'd replace "Should I use 10 or 100 seconds?" with "Should I use
> TIMEOUT_10_SEC or TIMEOUT_100_SEC?", while replacing "I want 40 seconds!"
> with "Danmed, I want 40 seconds, but that's not an option!".
>
> BTW: If you don't know about which timeout you should use, you should think
> about mowing the lawn instead. ΒΆΒΆ
It's not always that simple. If you code drivers or network protocols,
it might seem easy, but a lot of the VM for example is riddled with
rather arbitrary heuristics. Suppose we do slab cache reaping at 1HZ
(for no really good reason)... what I want to do with that guy is to
get maximum power savings when the CPU is idle, however I don't want to
wait infinitely long because that's leaving work to do when the CPU
finally does wake up, and it also ties up memory. I want the minimum
timeout that gives maximum power saving (say, within 99.9% of theoretical
maximum).
Can you tell me how to achieve this, or do you have lawn to mow too? ;)
OK, today we probably just add a few seconds of slop and forget about it,
but actually in future if we might want to power down most of the system
between key strokes, we might want 10s of seconds of sleep time.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists