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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <51C4713C.5060505@linux.intel.com>
Date:	Fri, 21 Jun 2013 08:29:00 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Morten Rasmussen <morten.rasmussen@....com>
CC:	David Lang <david@...g.hm>, 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 <Catalin.Marinas@....com>
Subject: Re: power-efficient scheduling design

On 6/21/2013 1:50 AM, Morten Rasmussen wrote:
>>> in control of the p-state selection and changes it fast enough to match
>>> the current load, the scheduler doesn't have to care? By fast enough I
>>> mean, faster than the scheduler would notice if a cpu was temporarily
>>> overloaded at a low p-state. In that case, you wouldn't need
>>> cpufreq/p-state hints, and the scheduler would only move tasks between
>>> cpus when cpus are fully loaded at their max p-state.
>>
>> with the migration hint, I'm pretty sure we'll be there today typically.
>
> A hint when a task is moved to a new cpu is too late if the migration
> shouldn't have happened at all. If the scheduler knows that the cpu is
> able to switch to a higher p-state it can decide to wait for the p-state
> change instead of migrating the task and waking up another cpu.

ok maybe I am missing something
but at least on the hardware I am familiar with (Intel and somewhat AMD),
the frequency (and voltage) when idle is ... 0 Hz... no matter what the OS chose for when the CPU is running.
And when coming out of idle, as part of the cost of that, is ramping up to something
appropriate.

And such ramps are FAST. Changing P state is as a result generally quite fast as well...
think "single digit microseconds" kind of fast.
Much faster than waking a CPU up in the first place (by design.. since a wakeup of a CPU
includes effectively a P state change)

I read your statement as "lets wait for the idle CPU to ramp its frequency up first",
which doesn't really make sense to me...



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