From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261929AbULPMTh (ORCPT ); Thu, 16 Dec 2004 07:19:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261931AbULPMTh (ORCPT ); Thu, 16 Dec 2004 07:19:37 -0500 Received: from witte.sonytel.be ([80.88.33.193]:58599 "EHLO witte.sonytel.be") by vger.kernel.org with ESMTP id S261929AbULPMTe (ORCPT ); Thu, 16 Dec 2004 07:19:34 -0500 Date: Thu, 16 Dec 2004 13:17:30 +0100 (MET) From: Geert Uytterhoeven To: Gabriel Paubert cc: Alan Cox , Eric St-Laurent , Russell King , Stefan Seyfried , Con Kolivas , Pavel Machek , Linux Kernel Mailing List , Andrea Arcangeli Subject: Re: dynamic-hz In-Reply-To: <20041216091032.GA9774@iram.es> Message-ID: References: <20041211142317.GF16322@dualathlon.random> <20041212163547.GB6286@elf.ucw.cz> <20041212222312.GN16322@dualathlon.random> <41BCD5F3.80401@kolivas.org> <41BD483B.1000704@suse.de> <20041213135820.A24748@flint.arm.linux.org.uk> <1102949565.2687.2.camel@localhost.localdomain> <1102983378.9865.11.camel@orbiter> <1103133841.3180.1.camel@localhost.localdomain> <20041216091032.GA9774@iram.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 16 Dec 2004, Gabriel Paubert wrote: > On Wed, Dec 15, 2004 at 06:04:03PM +0000, Alan Cox wrote: > > On Maw, 2004-12-14 at 00:16, Eric St-Laurent wrote: > > > On a related subject, a few months ago you posted a patch which added a > > > nice add_timeout()/timeout_pending() API and converted many (if not > > > most) drivers to use it. > > > > > > If I remember correctly it did not generate much comments and the work > > > was not pushed into mainline. > > > > > > I think it's a nice cleanup, IMHO the time_(before|after)(jiffies, ...) > > > construct is horrible. > > > > > > Any chance to resurrect this work ? > > > > I plan to ressurect it when I have a little time but with some small > > additions from the original work. Several people said "it should be mS > > not HZ" and someone at OLS proposed that the API also includes an > > accuracy guide so that systems using programmed wakeups can aggregate > > timers when accuracy doesn't matter. > > I suspect people who want to push HZ to 10000 won't be happy with > milliseconds since it would not give them a resolution of one jiffy. > > So the options are: > 1) microseconds, allows up to roughly half an hour (signed) > or an hour (unsigned). > 2) nanoseconds, needs 64 bits, nice for 64 bit machines but > at the risk of bloat on 32 bit ones. > 3) timespecs, somewhat wasteful on 64 bit machines (two longs). > > I believe 1) is the best compromise. Yep. And if the need for ns arises, add a _different_ function (e.g. *_ns()) to wait with ns-resolution. 64 bit is probably not needed, who wants to wait for more than a few seconds with ns-resolution? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds