Re: [patch] jiffies wraparound [Re: 2.1.125 Show stopper list: Draft]

Paul Barton-Davis (pbd@Op.Net)
Sat, 24 Oct 1998 11:28:54 -0300


>From: Olivier Galibert <galibert@pobox.com>
>Date: Sat, 24 Oct 1998 02:54:41 +0200
>Subject: Re: [patch] jiffies wraparound [Re: 2.1.125 Show stopper list: Draft]
>
>On Fri, Oct 23, 1998 at 05:44:57PM -0300, Paul Barton-Davis wrote:
>> Don't we want applications to be able to work as well as
>> possible ? If I have a box capable of support HZ=1000, then my user
>> level application can reasonably ask for an itimer of < 10ms. If the
>> value of HZ=100, this makes no sense, and causes erratic timing
>> behaviour in the application. Why is it so wrong to be able to ask
>> "whats the minimum value for a timer that makes sense ?", which is
>> effectively a function of HZ ?
>
>The setitimer resolution is not defined to be HZ. It is perfectly
>reasonable to think that in the future, with the increase of
>soft-RTism in the kernel, timers will be automagically adapted to give
>the best precision available to such timers.
>
>Face it, HZ is obsolete. You don't want a 10ms (or 1ms) resolution on
>everything you do anymore. You want the shortest possible latency on
>events (which mainly means rescheduling after interrupts and/or IPCs)
>for good interactive behaviour. You want long timeslices on
>cpu-burning processes to reduce cache effects. You want precise
>timers. Saying that HZ rules them all is innefficient.

I don't disagree with this. I even use the UTIME patches sometimes to
give microsecond kernel timer resolution, and they do exactly what you
describe: vary the frequency of the clock interrupt.

But you're missing the semantic point I was trying to make here. I
don't care if HZ itself is exported, or if there's a syscall to
fulfill the same role, but there has to be some way to ask the kernel
"whats the minimum value of a timer that i can reasonably ask for and
expect to get it serviced within X% of the correct time" ?

Right now, this is overwhelmingly a function of HZ. If in the future,
its more complex than that, fine, but right now, HZ is it.

--p

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