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

["Nish Aravamudan" <nish.aravamudan@gmail.com>]

On 7/16/07, Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> Nish Aravamudan wrote:
>
> > Well, before these changes, the only guarantee msleep() could make,
> > just like the only guarantee schedule_timeout() could make, was that
> > it would not return early. The 1-jiffy sleep was always tough to deal
> > with, because of rounding and such. And it's simply exacerbated with
> > HZ=100. It's not technically 20 times longer in all cases, it's 2
> > jiffies longer, which depends on HZ, so varies from 2 msecs longer to
> > 20 msecs longer.
>
> I don't think you should rely on anything else actually, because Linux
> is not an RT OS. If your driver needs a specific sequence in a given
> amount of time, you have to do something like disable interrupts and
> use delays.

I agree -- I wasn't trying to indicate what one should or should not
do. Just tried to provide some insight into the intent behind the
interfaces. They were never meant to be precise, per se -- simply
guaranteeing the request would be satisfied, with no upper bound. I
agree that if timing really is that critical then delays or more
accurate timing specifications would be appropriate (one reason to use
msecs_to_jiffies() and co. rather than jiffies directly in drivers,
perhaps).

Thanks,
Nish
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/