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
| ||
|
Date: Tue, 22 Jul 2008 16:04:40 +0200 From: Rene Herman <rene.herman@...access.nl> To: Arjan van de Ven <arjan@...radead.org> CC: David Woodhouse <dwmw2@...radead.org>, linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...e.hu>, Stephen Hemminger <shemminger@...tta.com> Subject: Re: [RFC] Imprecise timers. On 22-07-08 14:54, Arjan van de Ven wrote: > On Tue, 22 Jul 2008 09:19:02 +0200 > Rene Herman <rene.herman@...access.nl> wrote: > >> On 22-07-08 05:02, David Woodhouse wrote: >> >>> Many users of timers don't really care too much about exactly when >>> their timer fires -- and waking a CPU to satisfy such a timer is a >>> waste of power. This patch implements a 'range' timer which will >>> fire at a 'convenient' moment within given constraints. >>> >>> It's implemented by a deferrable timer at the beginning of the >>> range, which will run some time later when the CPU happens to be >>> awake. And a non-deferrable timer at the hard deadline, to ensure >>> it really does happen by then. >> Are there actually users for this (not just in theory)? The >> deferrable timer sort of sounds like all I'd ever want if I, as you >> say, wouldn't really care... > > there's a few; mostly around hardware timeout..For example Stephen want > it for his drivers. Hardware I've dealt with is (almost? can't remember anything else) exlusively minimal delays and as such this thing seemed like perhaps a bit over-apisized... > EXT3 journal flushing is another one where we can easily say > "between 4 and 7 seconds" rather than "exactly at 5" This a nice-ish example though. It might be considered necessary to make the current commit delay when set explicitly be the non-deferrable upper bound but almost none do I guess. Rene. -- 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