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 21:40:35 +0800
From:	Alex Shi <alex.shi@...el.com>
To:	Ingo Molnar <mingo@...nel.org>
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

On 02/20/2013 05:37 PM, Ingo Molnar wrote:
> 
> * Alex Shi <alex.shi@...el.com> wrote:
> 
>> Current scheduler behavior is just consider for larger 
>> performance of system. So it try to spread tasks on more cpu 
>> sockets and cpu cores
>>
>> To adding the consideration of power awareness, the patchset 
>> adds 2 kinds of scheduler policy: powersaving and balance. 
>> They will use runnable load util in scheduler balancing. The 
>> current scheduling is taken as performance policy.
>>
>> performance: the current scheduling behaviour, try to spread tasks
>>                 on more CPU sockets or cores. performance oriented.
>> powersaving: will pack tasks into few sched group until all LCPU in the
>>                 group is full, power oriented.
>> balance    : will pack tasks into few sched group until group_capacity
>>                 numbers CPU is full, balance between performance and
>> 		powersaving.
> 
> Hm, so in a previous review I suggested keeping two main 
> policies: power-saving and performance, plus a third, default 
> policy, which automatically switches between these two if/when 
> the kernel has information about whether a system is on battery 
> or on AC - and picking 'performance' when it has no information.

I will try to add a default policy according to your suggestion.
> 
> Such an automatic policy would obviously be useful to users - 
> and that is what makes such a feature really interesting and a 
> step forward.
> 
> I think Peter expressed similar views: we don't want many knobs 
> and states, we want two major goals plus an (optional but 
> default enabled) automatism.

I got the message. thanks for reclaim again.

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

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.
It was introduced just because SMT LCPU in intel arch. SMT thread is a
independent LCPU in software, but its cpu power(smt_gain 1178 / 2 = 589)
is smaller than a normal CPU(1024). So, the group capacity is just 1 for
a 2 SMT thread core. So, on policy, just one task assign to one core
normally.


> 
> Is your 'balance' policy implementing that suggestion?
> If not, why not?
> 
> Thanks,
> 
> 	Ingo
> 


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