linux-kernel - Re: power-efficient scheduling design

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 24 Jun 2013 08:26:21 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
CC:	Catalin Marinas <catalin.marinas@....com>,
	Morten Rasmussen <morten.rasmussen@....com>,
	David Lang <david@...g.hm>,
	"len.brown@...el.com" <len.brown@...el.com>,
	"alex.shi@...el.com" <alex.shi@...el.com>,
	"corbet@....net" <corbet@....net>,
	"peterz@...radead.org" <peterz@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"efault@....de" <efault@....de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	"preeti@...ux.vnet.ibm.com" <preeti@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"pjt@...gle.com" <pjt@...gle.com>, Ingo Molnar <mingo@...nel.org>
Subject: Re: power-efficient scheduling design


>> I guess it depends on the system
>
> Sort-of. We have something similar with threads on ppc. IE, the core can
> only really stop if all threads are. From a Linux persepctive it's a
> matter of how we define the scope of that 'cluster' Catalin is talking
> about. I'm sure you do too.
>
> Then there is the package, which adds MC etc...
>
>> the very first cpu needs to power on
>> * the core itself
>> * the "cluster" that you mention
>> * the memory controller
>> * the memory (out of self refresh)
>>
>> while the second cpu needs
>> * the core itself
>> * maybe a second cluster
>>
>> normally on Intel systems, the memory power delta is quite significant
>> which then means the efficiency of the second core is huge compared to
>> running things in sequence.
>
> What's your typical latency for bringing an MC back (and memory out of
> self refresh) ? IE. Basically bringing a package back up ?

to bring the system back up if all cores in the whole system are idle and power gated,
memory in SR etc... is typically < 250 usec (depends on the exact version
of the cpu etc). But the moment even one core is running, that core will keep the system
out of such deep state, and waking up a consecutive entity is much faster

to bring just a core out of power gating is more in the 40 to 50 usec range

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