On 7/16/07, Nick Piggin <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
