[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160531180030.GS18670@intel.com>
Date: Wed, 1 Jun 2016 02:00:30 +0800
From: Yuyang Du <yuyang.du@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...nel.org, linux-kernel@...r.kernel.org,
umgwanakikbuti@...il.com, bsegall@...gle.com, pjt@...gle.com,
morten.rasmussen@....com, vincent.guittot@...aro.org,
dietmar.eggemann@....com
Subject: Re: [RFC PATCH 1/2] sched: Clean up SD_BALANCE_WAKE flags in sched
domain build-up
On Tue, May 31, 2016 at 12:41:21PM +0200, Peter Zijlstra wrote:
> On Tue, May 31, 2016 at 09:31:32AM +0800, Yuyang Du wrote:
> > On Tue, May 31, 2016 at 11:21:46AM +0200, Peter Zijlstra wrote:
> > > On Tue, May 31, 2016 at 09:11:37AM +0800, Yuyang Du wrote:
> > > > The SD_BALANCE_WAKE is irrelevant in the contexts of these two removals,
> > > > and in addition SD_BALANCE_WAKE is not and should not be set in any
> > > > sched_domain flags so far.
> > >
> > > This Changelog doesn't make any sense...
> >
> > How? SD_BALANCE_WAKE is not in any sched_domain flags (sd->flags), even if
> > it is, it is not used anywhere, no?
>
> It is and it is. See select_task_fair_rq():
>
> if (tmp->flags & sd_flags)
>
> Now, as long as WAKE_AFFINE is also set, its hard to actually get into
> the find_idlest_cpu() balancing, but if you clear all that you will
> still get there.
Well, that is very true, and the next patch (2/2) just makes all this
what this is supposed to be: the SD_BALANCE_WAKE is a meaningful sched_domain
flag.
This particular patch is a pure cleanup, may I amend the changelog to:
According to the comment: "turn off/on idle balance on this domain",
the SD_BALANCE_WAKE has nothing to do with idle balance, so clean them up.
Powered by blists - more mailing lists