On tickless kernels, is the general consensus that for non-embedded
systems, selecting HZ=1000 gives slightly more throughput in
particular situations than HZ=100 or 250, due to finer timer
intervals/granularity?
(low HZ used to cause problems with low-rate QoS packet queues when
timer scheduling was selected)
Thanks,
Daniel
--
Daniel J Blueman
On Sat, 19 Sep 2009 15:47:24 +0100
Daniel J Blueman <[email protected]> wrote:
> On tickless kernels, is the general consensus that for non-embedded
> systems, selecting HZ=1000 gives slightly more throughput in
> particular situations than HZ=100 or 250, due to finer timer
> intervals/granularity?
it's not about throughput. It's about latency for some things....
although now that select/poll and co use hrtimers it's not as critical
anymore.
the HZ timers aren't used much for anything time-critical nowadays.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Sat, Sep 19, 2009 at 3:55 PM, Arjan van de Ven <[email protected]> wrote:
> On Sat, 19 Sep 2009 15:47:24 +0100
> Daniel J Blueman <[email protected]> wrote:
>
>> On tickless kernels, is the general consensus that for non-embedded
>> systems, selecting HZ=1000 gives slightly more throughput in
>> particular situations than HZ=100 or 250, due to finer timer
>> intervals/granularity?
>
> it's not about throughput. It's about latency for some things....
> although now that select/poll and co use hrtimers it's not as critical
> anymore.
>
> the HZ timers aren't used much for anything time-critical nowadays.
Agreed. Do you think there is still a small case for moving to HZ=1000
(given it's effectively free) in situations like:
jiffies_to_transmit = port->baud?(1 + charsleft * 10 * HZ / port->baud):0;
<applying plausible figures>
(gdb) p (1 + 10 * 10 * 1000 / 38400) * 1
$3 = 3
(gdb) p (1 + 10 * 10 * 250 / 38400) * 4
$5 = 4
-> HZ=250 causes a 33% longer sleep than expected
perhaps?
--
Daniel J Blueman
On Sat, 2009-09-19 at 18:50 +0100, Daniel J Blueman wrote:
> Agreed. Do you think there is still a small case for moving to HZ=1000
> (given it's effectively free) in situations like:
Sure HZ=1000 gives you more accurate sleeps, that's kind of the point,
but since when has it been "effectively free"?
http://lwn.net/Articles/331607/
--Ben.
On 09/20/2009 01:12 AM, Ben Nizette wrote:
> On Sat, 2009-09-19 at 18:50 +0100, Daniel J Blueman wrote:
>
>> Agreed. Do you think there is still a small case for moving to HZ=1000
>> (given it's effectively free) in situations like:
>
> Sure HZ=1000 gives you more accurate sleeps, that's kind of the point,
> but since when has it been "effectively free"?
> http://lwn.net/Articles/331607/
i'd be curious, what effect does it have on userspace applications?
like, does it effect the wakeup latency of userspace (pthread)
mutexes/conditions or posix semaphores?
thnx, tim
--
[email protected]
http://tim.klingt.org
Desperation is the raw material of drastic change. Only those who can
leave behind everything they have ever believed in can hope to escape.
William S. Burroughs
On Sun, 20 Sep 2009 09:34:30 +0200
Tim Blechmann <[email protected]> wrote:
> On 09/20/2009 01:12 AM, Ben Nizette wrote:
> > On Sat, 2009-09-19 at 18:50 +0100, Daniel J Blueman wrote:
> >
> >> Agreed. Do you think there is still a small case for moving to
> >> HZ=1000 (given it's effectively free) in situations like:
> >
> > Sure HZ=1000 gives you more accurate sleeps, that's kind of the
> > point, but since when has it been "effectively free"?
> > http://lwn.net/Articles/331607/
>
> i'd be curious, what effect does it have on userspace applications?
> like, does it effect the wakeup latency of userspace (pthread)
> mutexes/conditions or posix semaphores?
the impact to userspace should be zero nowadays since select/poll/etc
moved to hrtimers, which are HZ-independent.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org