linux-kernel - Re: [RFC PATCH 1/2] sched: Clean up SD_BALANCE

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]

Message-ID: <CAKfTPtDveMbwiphH8xBsquYdwind8xXGLqLhpOzgEqPcWdnzhg@mail.gmail.com>
Date:	Thu, 2 Jun 2016 08:56:40 +0200
From:	Vincent Guittot <vincent.guittot@...aro.org>
To:	Yuyang Du <yuyang.du@...el.com>
Cc:	Mike Galbraith <umgwanakikbuti@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...nel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Benjamin Segall <bsegall@...gle.com>,
	Paul Turner <pjt@...gle.com>,
	Morten Rasmussen <morten.rasmussen@....com>,
	Dietmar Eggemann <dietmar.eggemann@....com>
Subject: Re: [RFC PATCH 1/2] sched: Clean up SD_BALANCE_WAKE flags in sched
 domain build-up

On 1 June 2016 at 21:35, Yuyang Du <yuyang.du@...el.com> wrote:
> On Wed, Jun 01, 2016 at 11:24:45AM +0200, Vincent Guittot wrote:
>> >
>> > So with the patch, we will have a little bit semantic change, SD_BALANCE_WAKE
>> > implies SD_WAKE_AFFINE if allowed, and will favor "fast path" if possible. I don't
>> > think we should do anything otherwise.
>>
>> Why should we not do anything else ?
>>
>> The current default configuration is to only use the wake_affine path.
>> With your changes, the default configuration will try to use wake
>> affine and will fall back to long load balance sequence if wake affine
>> doesn't find a sched_domain
>>
>> That's a major changes in the behavior
>
> Well, I won't argue that this hasn't changed, but I'd argue that this change
> isn't a bad change: (a) it restores the flags to their meanings and makes them

Have you any proof that this change is not a bad thing ? Moreover have
you got proof that it's a good thing ? Changing the meaning and the
behavior of flags, just because you find it elegant, doesn't seem to
be enough for me.

So if you just want to rename the flags please keep current behavior unchange

> more "elegant", (b) we definitely need further work to improve
> select_task_rq_fair(), there has already been a comment marked XXX, right? :)