now that both amd64 and i386 have a tickless kernel
it makes sense to enable CONFIG_HZ_1000 for both.
the current consumption is no longer a trouble and
we gain better interactive response. the timer
interrupts should no longer reduce server perf.

back in the early 2.6 game i disabled preempt,
due to strange driver bugs poping up, now that
this seems to have been cleared upstream all
major distros ship with the PREEMPT_VOLUNTARY on,
PREEMPT_BKL

--
maks


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hello,

How is the performance impact of HZ_1000 and tickless versus HZ_100?

If the impact is as big as the HZ_100 vs HZ_1000 one, I think it's
time to have a desktop/laptop and a server kernel image for amd64.

The desktop image would get HZ_1000, tickless and preemption.

The server image would get HZ_100, no preemption, 255 CPUs support,
and xen/vserver flavours.


Best regards
Frederik Schüler

On Wed, Nov 28, 2007 at 03:18:01PM +0100, maximilian attems wrote:
> now that both amd64 and i386 have a tickless kernel
> it makes sense to enable CONFIG_HZ_1000 for both.
> the current consumption is no longer a trouble and
> we gain better interactive response. the timer
> interrupts should no longer reduce server perf.
>
> back in the early 2.6 game i disabled preempt,
> due to strange driver bugs poping up, now that
> this seems to have been cleared upstream all
> major distros ship with the PREEMPT_VOLUNTARY on,
> PREEMPT_BKL
>
> --
> maks
>
>
> --
> To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

--
ENOSIG

On Sun, Dec 02, 2007 at 12:39:36AM +0100, Frederik Schueler wrote:

> How is the performance impact of HZ_1000 and tickless versus HZ_100?

> If the impact is as big as the HZ_100 vs HZ_1000 one, I think it's
> time to have a desktop/laptop and a server kernel image for amd64.

> The desktop image would get HZ_1000, tickless and preemption.

> The server image would get HZ_100, no preemption, 255 CPUs support,
> and xen/vserver flavours.

FWIW, I think "desktop" and "server" are misleading descriptions here. It's
my impression that there are lots of servers in production that would also
benefit from power savings as a result of tickless. Perhaps "standard" and
"performance" would be better descriptors here?

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hello,

On Sat, Dec 01, 2007 at 03:56:01PM -0800, Steve Langasek wrote:
> FWIW, I think "desktop" and "server" are misleading descriptions here. It's
> my impression that there are lots of servers in production that would also
> benefit from power savings as a result of tickless.

I sincerely doubt it. Current servers with dualcore opterons or quadcore
xeons pull between, 200-400W idle. Add more FB-dimms, and you get more
5W each.
A tickless kernel, wich might reduce the consumption by best-case 1W, is
just a joke in this case.

OTOH of course, if you have a laptop consuming 10-15W, and get it down
by 1W, I'd love to enable tickless, thats some 10-20 minutes of battery
time.

Having servers downclock the CPU when idle is a good idea, especially
if you have active/failover systems where the second box just waits for
the first one to fail. But this is cpufreq, not tickless or HZ.

> Perhaps "standard" and
> "performance" would be better descriptors here?

Which being what?

Given the nature of the settings, powersave and standard could be better
names.

Best regards
Frederik Schüler

--
ENOSIG