linux-kernel - Re: [RFC] schedule_timeout

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Jul 2008 00:45:25 -0400
From:	David Woodhouse <dwmw2@...radead.org>
To:	Nick Piggin <nickpiggin@...oo.com.au>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, arjan@...radead.org
Subject: Re: [RFC] schedule_timeout_range()

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

--
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/