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]

Message-ID: <51ACAF4D.3010600@linux.intel.com>
Date:	Mon, 03 Jun 2013 07:59:25 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Ingo Molnar <mingo@...nel.org>
CC:	Morten Rasmussen <morten.rasmussen@....com>, alex.shi@...el.com,
	peterz@...radead.org, preeti@...ux.vnet.ibm.com,
	vincent.guittot@...aro.org, efault@....de, pjt@...gle.com,
	linux-kernel@...r.kernel.org, linaro-kernel@...ts.linaro.org,
	len.brown@...el.com, corbet@....net,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	tglx@...utronix.de
Subject: Re: power-efficient scheduling design

>
>   - enumeration of idle states
>
>   - how long it takes to enter+exit a particular idle state
>
>   - [ perhaps information about how destructive to CPU caches that
>       particular idle state is. ]
>
>   - new driver entry point that allows the scheduler to enter any of the
>     enumerated idle states. Platform code will not change this state, all
>     policy decisions and the idle state is decided at the power saving
>     policy level.
>
> All of this combines into a 'cost to enter and exit an idle state'
> estimation plus a way to enter idle states. It should be presented to the
> scheduler in a platform independent fashion, but without policy embedded:
> a low level platform driver interface in essence.


you're missing an aspect.
Deeper idle states on one core, allow (on Intel and AMD at least) the other cores to go faster.
So it's not so simple as "if I want more performance, go less deep". By going less deep you also reduce
overall performance of the system... as well as increase the power usage.

This aspect really really cannot be ignored, it's quite significant today, and going forward
is only going to get more and more significant.


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