linux-kernel - Re: [PATCH 08/32] nohz: Try not to give the timekeeping duty to an adaptive tickless cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120330013453.GC2571@somewhere.redhat.com>
Date:	Fri, 30 Mar 2012 03:34:55 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Christoph Lameter <cl@...ux.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	linaro-sched-sig@...ts.linaro.org,
	Alessio Igor Bogani <abogani@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Avi Kivity <avi@...hat.com>,
	Chris Metcalf <cmetcalf@...era.com>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Geoff Levand <geoff@...radead.org>,
	Gilad Ben Yossef <gilad@...yossef.com>,
	Ingo Molnar <mingo@...nel.org>,
	Max Krasnyansky <maxk@...lcomm.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Stephen Hemminger <shemminger@...tta.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Sven-Thorsten Dietrich <thebigcorporation@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Zen Lin <zen@...nhuawei.org>,
	Dimitri Sivanich <sivanich@....com>
Subject: Re: [PATCH 08/32] nohz: Try not to give the timekeeping duty to an
 adaptive tickless cpu

On Tue, Mar 27, 2012 at 11:08:05AM -0500, Christoph Lameter wrote:
> On Tue, 27 Mar 2012, Frederic Weisbecker wrote:
> 
> > > Any way to manually specify which cpu? We f.e. always "sacrifice" cpu 0
> > > for OS activities. We would like to have all Os processing things
> > > restricted to cpu 0 so that the rest of the processors do not experience
> > > the OS noise.
> >
> > Somebody tries to do this: https://lkml.org/lkml/2011/11/8/346
> >
> > But in the case of nohz cpusets there is a problem to solve:
> >
> > What if every CPUs are tickless (idle or busy), who must take
> > the timekeeping duty? Should we pick one of the busy CPUs? Or
> > keep one CPU with the tick even if it's idle? How do we choose
> > this CPU?
> 
> Then its the users fault because he specified the processor to use. There
> is no picking if its manually assigned.

If you can only tune the timekeeping binding to a single CPU, what happens when
that CPU goes idle and it's the only CPU that is not in a nohz cpuset? If there
are other CPUs that are busy but tickless, they need the timekeeping to be
maintained. This means we need to keep the periodic tick on the CPU where we
binded the timekeeping, even if that CPU is idle. That's not good for powersaving.

Let's put the example above with a practical example. We have 4 CPUs.
CPU 0, 2 and 3 are in a nohz cpuset. CPU 1 is "normal". As long as CPU 1
is busy we are fine and we can give it the timekeeping duty. Now it runs
idle and the other CPUs (0, 2, 3) are busy and they run without the tick.

We have the choice between:

1) Keep the periodic tick on CPU 1, even if it's idle, and let the timekeeping
duty be handled there.

2) Pick either CPU 0, 2 or 3 and restart the tick in one of them to handle
the timekeeping duty.

I think both propositions are relevant, it just depends on what the user
wants. 1) will consume more power because the periodic tick prevents CPU 1
from entering low power mode. But this is good if you want to ensure isolation
on CPU 0, 2 and 3.
2) is good if you want powersaving and you don't care about isolation: you just
want to run tickless when possible but no big deal if we can't.

If you can tune the timekeeping binding to only one CPU you can't make
such finegrained decision. You rather need this timekeeping duty to be
defined on a set of CPUs. And cpuset is of course a very good candidate
to define properties on a set of CPUs ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/