[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20080521190103.GA19261@elf.ucw.cz>
Date: Wed, 21 May 2008 21:01:03 +0200
From: Pavel Machek <pavel@...e.cz>
To: Jeff Garzik <jeff@...zik.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org
Subject: Re: better msleep for drivers
Hi!
>>>> Still longer term I suppose there's really no way around having accurate
>>>> sleep functions and it's probably better to start testing earlier than later.
>>> No objections, but we should not do that with a stupid msleep
>>> replacement interface; instead we should expose a flexible in kernel
>>> variant of hrtimer_nanosleep() which lets the user utilize
>>> ABS/REL_TIME and the different clocks. A msleep helper can be built on
>>> top of this very easily.
>>
>> While you are at it... it would be cool to have
>>
>> 'mdelay(2500 msec), but it is okay to wait 100msec more' -- type
>> interface, so we could use that for nohz benefit.
>>
>> Currently, mdelay is 'it is okay to wait 10msec more' interface, and
>> it would be nice to have that explicit.
>
> eh, I think you transposed mdelay with msleep?
>
> msleep() is the "it is okay to wait longer than I said" interface, not
> mdelay(). mdelay() has always been non-sleeping and exact (as much as the
> delay loop allows)
Okay, I was a bit confused.
Actually, both can delay for longer... msleep() in case of scheduling
load, mdelay() in case of interrupt load...
But the above was about hrtimer_nano*sleep*(), so that "how much
latency we can tolarate" parameter would still be good.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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