linux-kernel - Re: [patch v5 04/15] sched: add sched balance policies in kernel

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]

Date:	Wed, 20 Feb 2013 16:41:01 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Alex Shi <alex.shi@...el.com>
Cc:	torvalds@...ux-foundation.org, mingo@...hat.com,
	peterz@...radead.org, tglx@...utronix.de,
	akpm@...ux-foundation.org, arjan@...ux.intel.com, bp@...en8.de,
	pjt@...gle.com, namhyung@...nel.org, efault@....de,
	vincent.guittot@...aro.org, gregkh@...uxfoundation.org,
	preeti@...ux.vnet.ibm.com, viresh.kumar@...aro.org,
	linux-kernel@...r.kernel.org, morten.rasmussen@....com
Subject: Re: [patch v5 04/15] sched: add sched balance policies in kernel


* Alex Shi <alex.shi@...el.com> wrote:

> Now there is just 2 types policy: performance and 
> powersaving(with 2 degrees, powersaving and balance).

I don't think we really want to have 'degrees' to the policies 
at this point - we want each policy to be extremely good at what 
it aims to do:

 - 'performance' should finish jobs in in the least amount of 
    time possible. No ifs and whens.

 - 'power saving' should finish jobs with the least amount of 
    watts consumed. No ifs and whens.

> powersaving policy will try to assign one task to each LCPU, 
> whichever the LCPU is SMT thread or a core. The balance policy 
> is also a kind of powersaving policy, just a bit less 
> aggressive. It will try to assign tasks according group 
> capacity, one task to one capacity.

The thing is, 'a bit less aggressive' is an awfully vague 
concept to maintain on a long term basis - while the two 
definitions above are reasonably deterministic which can be 
measured and improved upon.

Those two policies and definitions are also much easier to 
communicate to user-space and to users - it's much easier to 
explain what each policy is supposed to do.

I'd be totally glad if we got so far that those two policies 
work really well. Any further nuance visible at the ABI level is 
I think many years down the road - if at all. Simple things 
first - those are complex enough already.

Thanks,

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