On 7/16/07, Ray Lee <[email protected]> wrote:
On 7/16/07, Roman Zippel <[email protected]> wrote:
> On Mon, 16 Jul 2007, Jonathan Corbet wrote:
> > > 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).
> >
> > That's a possibility, I admit I haven't benchmarked it. I will say that
> > I don't think it will be enough to matter - msleep() is not a hot-path
> > sort of function. Once the system is up and running it almost never
> > gets called at all - at least, on my setup.
>
> That's a bit my problem - we have to consider other setups as well.
> Is it worth converting all msleep users behind their back or should we
> just a provide a separate function for those who care?
As a driver author (2.4 timeframe, embedded platform, see gitinc.com
for the hardware description), I would rather msleep did what it says
it's going to do. If the current one can wait 20 times longer than you
ask for, then that's just broken.
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.
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]
