tickless and HZ=1000 throughput advantage?

10 views
Skip to first unread message

Daniel J Blueman

unread,
Sep 19, 2009, 10:50:05 AM9/19/09
to
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
--
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

unread,
Sep 19, 2009, 11:00:13 AM9/19/09
to
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.

--
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

unread,
Sep 19, 2009, 2:00:11 PM9/19/09
to
On Sat, Sep 19, 2009 at 3:55 PM, Arjan van de Ven <ar...@infradead.org> wrote:
> 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

unread,
Sep 19, 2009, 7:20:05 PM9/19/09
to
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.

Tim Blechmann

unread,
Sep 20, 2009, 3:40:05 AM9/20/09
to
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

--
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

signature.asc

Arjan van de Ven

unread,
Sep 20, 2009, 3:50:05 AM9/20/09
to
On Sun, 20 Sep 2009 09:34:30 +0200
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

Reply all
Reply to author
Forward
0 new messages