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:	Tue, 18 Jun 2013 12:36:42 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	David Lang <david@...g.hm>
CC:	Morten Rasmussen <morten.rasmussen@....com>,
	Ingo Molnar <mingo@...nel.org>,
	"alex.shi@...el.com" <alex.shi@...el.com>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"preeti@...ux.vnet.ibm.com" <preeti@...ux.vnet.ibm.com>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"efault@....de" <efault@....de>, "pjt@...gle.com" <pjt@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>,
	"len.brown@...el.com" <len.brown@...el.com>,
	"corbet@....net" <corbet@....net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>, catalin.marinas@....com
Subject: Re: power-efficient scheduling design

On 6/18/2013 10:47 AM, David Lang wrote:

>
> so this sounds to me like the process for changing settings on this Intel hardware is a two phase process
>
> something looks up what should be possible and says "switch to mode X"

more a case of "I would like to request X"
it's not a mandate, it's a polite request/suggestion

> after mode switch happens it then looks and finds "it's now in mode Y"

you don't really know what you are in, you can only really know on average what you were in over
some time in the past.
As such, Y is not really discrete/enumeratable (well since it's all fixed point math, it is, sure, in steps if 1 Hz)

the "current" thing is changing all the time on a very fine grained timescale, depending on
what the other cores in the system are doing, what graphics is doing, what the temperature is etc etc.


> And if you can't tell what mode you are in, or what the expected performance characteristics are, then you can't possibly do any intellegant allocations.

you can tell what you were in looking in the rear-view mirror. you have no idea what it'll be going forward.
>
> If Intel is doing this for current CPUs, I expect that they will fix this before too much longer.

I'm pretty sure that won't happen, and I'm also pretty sure the other CPU vendors are either there today (AMD) or
will be there in the next few years (ARM).
It's the nature of how CPUs do power and thermal management and the physics behind that.

>> You can look in hindsight what kind of performance you got (from some basic counters in MSRs), and the scheduler can use that to account backwards to what some process
>> got. But to predict what you will get in the future...... that's near impossible on any realistic system nowadays (and even more so in the future).
>
> If you have no way of knowing how much processing power you should expect to have on each core in the near future, then you have no way of allocating processes
> appropriately between the cores.
>
> It's bad enough trying to guess the needs of the processes, but if you also are reduced to guessing the capabilities of the cores, how can anything be made to work?

you can give some suggestions to the hardware. But how much you actually get can be off by 2x or more in either direction.
And most of that will depend on what other cores/graphics in the system are doing
(in terms of idle or their own requests and the amount of the total power budget they are consuming)


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