linux-kernel - Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events

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]

Date:	Thu, 24 Feb 2011 21:27:50 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Vincent Guittot <vincent.guittot@...aro.org>,
	linux-kernel@...r.kernel.org, linux-hotplug@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>, amit.kucheria@...aro.org,
	Rusty Russell <rusty@...tcorp.com.au>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH V5 2/2] tracing, perf : add cpu hotplug trace events

On Thu, 2011-02-24 at 20:11 +0000, Alan Cox wrote:
> > Anybody who is interested in the latency of cpu hotplug is deluding
> > himself, also cpu hotplug is _NOT_ a power management feature, so the
> > rest of your justification just disappeared as well.
> 
> Actually CPU hotplug is a power management feature on some devices where
> you need to shutdown one of the cores to enter low power modes.

Aren't we confusing things here? Surely simply idling a core is good
enough? Why would we want to go through the whole CPU hotplug dance
simply to enter a low power state?

> Remember we use it as part of the suspend paths and various processors
> nowdays drop into a suspend to RAM type state on CPU idling.

Which would illustrate the above point. CPU hotplug is a terribly
expensive op, and doing so from idle is really utterly ridiculous (nor
can we, idle is not supposed to schedule and cpu-hotplug needs to
schedule)

Why can't we do these things from the normal idle path, presumably these
state transitions are 'fast', so we can implement them as normal idle
modes. 

The scheduler has (due to power7 support) the ability to favour lower
cpu nrs when placing tasks, so idle !bsp (assuming cpu0 is the bsp) can
drop into their special state, and then when the bsp goes idle it can do
whatever it needs to do.

All that needs is to make sure smp_send_reschedule() can wake !bsp cores
from their special sleep state, but that's all arch code anyway.

I really see no reason to conflate cpu-hotplug and idle/power-states.

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