linux-kernel - Re: [PATCH/RFC] msleep() with hrtimers

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]

Message-ID: <20070716114734.GA12010@elte.hu>
Date:	Mon, 16 Jul 2007 13:47:34 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Roman Zippel <zippel@...ux-m68k.org>
Cc:	Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH/RFC] msleep() with hrtimers


* Roman Zippel <zippel@...ux-m68k.org> wrote:

> > Here's another approach: a reimplementation of msleep() and 
> > msleep_interruptible() using hrtimers.  On a system without real 
> > hrtimers this code will at least drop down to single-jiffy delays 
> > much of the time (though not deterministically so).  On my x86_64 
> > system with Thomas's hrtimer/dyntick patch applied, msleep(1) gives 
> > almost exactly what was asked for.
> 
> One possible problem here is that setting up that timer can be 
> considerably more expensive, for a relative timer you have to read the 
> current time, which can be quite expensive (e.g. your machine now uses 
> the PIT timer, because TSC was deemed unstable).

i dont think there's any significant overhead. The OLPC folks are pretty 
sensitive to performance, so if there was any genuine measurable 
overhead due to this, i'd expect them to report it. And even if there 
_was_ overhead, it would be well worth its price, the legacies of HZ are 
clearly biting the OLPC project here. The sooner we get rid of HZ 
dependencies and HZ artifacts, the better.

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