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: <4BB9F657.4050901@linux.intel.com>
Date:	Mon, 05 Apr 2010 07:40:23 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	paulmck@...ux.vnet.ibm.com
CC:	Dominik Brodowski <linux@...inikbrodowski.net>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Dmitry Torokhov <dtor@...l.ru>
Subject: Re: A few questions and issues with dynticks, NOHZ and powertop

On 4/4/2010 21:22, Paul E. McKenney wrote:
> On Sun, Apr 04, 2010 at 08:44:05PM -0700, Arjan van de Ven wrote:
>>> And you did mention offlining some CPUs above.  The folloiwng patch
>>> (from Lai Jiangshan) is needed to handle this case.
>>
>> btw on x86... don't offline CPUs if you want to save power.. it doesn't.
>> (at least not during idle.. and when you're busy it might save power,
>> but it won't save you energy normally)
>
> Hmmm...  The fact that offlining CPUs doesn't save power could form
> the basis of an interesting rationalization for my having ignored
> offlined CPUs in my original patch, I suppose.  ;-)
>
> So the proper approach is to affinity everything away from the CPUs
> in question so that they stay in dyntick-idle mode?

that is actually equivalently bad ;)

>  I must confess
> that I find this quite counter-intuitive -- and I suspect that I am
> not the only one who would expect offlined CPUs to drop to the
> lowest possible power consumption.

on x86 (other archs might be different), nowadays idle is VERY efficient.
(and the way to offline a cpu is to put it into the same deep C state as idle would)

the "offline is same power as idle" is only the part where you don't win energy.
the part where you lose energy is the part where you realize that you can only really put
the memory controller and memory in power saving state if all cpus are in idle.
If you offline a cpu (versus leaving it idle), and you have several tasks to run during an
activity burst (which are more common the more we group activity to save power), it can happen
that there are so many things to do that all remaining cpus can't handle it without the scheduler
delaying some tasks. At which point you delay putting the memory (controllers) in low power state
and you lose. In general, the winning strategy seems to be to finish things as quickly as you can,
eg on as many cpus as you have in the system to then let them all go idle.

(this is not always true if you're picking cpu frequency/voltages, but for idle states it tends
to be true. there's always cases where it isn't.... power is like that)
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ