linux-kernel - Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

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: <51E0244E.4090909@linux.intel.com>
Date:	Fri, 12 Jul 2013 08:44:14 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Catalin Marinas <catalin.marinas@....com>
CC:	Morten Rasmussen <Morten.Rasmussen@....com>,
	"mingo@...nel.org" <mingo@...nel.org>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"preeti@...ux.vnet.ibm.com" <preeti@...ux.vnet.ibm.com>,
	"alex.shi@...el.com" <alex.shi@...el.com>,
	"efault@....de" <efault@....de>, "pjt@...gle.com" <pjt@...gle.com>,
	"len.brown@...el.com" <len.brown@...el.com>,
	"corbet@....net" <corbet@....net>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>
Subject: Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal


> But on x86 you still have a P-state hint for the CPU and the scheduler
> could at least hope for more CPU performance. We can make the power
> scheduler ask the power driver for an increase or decrease of
> performance (as Preeti suggested) and give it the current load as
> argument rather than a precise performance/frequency level. The power
> driver would change the P-state accordingly and take the load into
> account (or ignore it, something like intel_pstate.c can do its own
> aperf/mperf tracking). But the power driver will inform the scheduler
> that it can't change the P-state further and the power scheduler can
> decide to spread the load out to other CPUs.


I am completely fine with an interface that is something like

void arch_please_go_faster(int cpunr);
void arch_please_go_fastest(int cpunr);
int arch_can_you_go_faster_than_now(int cpunr);

(maybe without the arguments and only make it for the local cpu, that would
make the implementation surely simpler)

with the understanding that these are instant requests (e.g. longer term policy will
clobber requests eventually).

it makes total sense to me for the scheduler to indicate "I need performance NOW".
Either when it sees it's on the verge of needing to load balance, or when it is about to schedule
a high priority (think realtime) task.

Part of the reason I like such interface is that it is a higher level one, it's a clear and high level enough
policy request that the hardware driver can translate into a hardware specific thing.

An interface that would be "put it at THIS much" is not. It's too low level and makes assumptions about
hardware things that change between generations/vendors that the scheduler really shouldn't know about.


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