tickless and HZ=1000 throughput advantage?
Daniel J Blueman
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Arjan van de Ven
Daniel J Blueman <daniel....@gmail.com> 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
Daniel J Blueman
> On Sat, 19 Sep 2009 15:47:24 +0100
> Daniel J Blueman <daniel....@gmail.com> 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
Ben Nizette
> 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.
Tim Blechmann
> 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
--
t...@klingt.org
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
Arjan van de Ven
Tim Blechmann <t...@klingt.org> 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