[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160331232059.GE22689@intel.com>
Date: Fri, 1 Apr 2016 07:20:59 +0800
From: Yuyang Du <yuyang.du@...el.com>
To: bsegall@...gle.com
Cc: peterz@...radead.org, mingo@...nel.org,
linux-kernel@...r.kernel.org, pjt@...gle.com,
morten.rasmussen@....com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, lizefan@...wei.com,
umgwanakikbuti@...il.com
Subject: Re: [PATCH RESEND v2 6/6] sched/fair: Remove unconditionally
inactive code
On Thu, Mar 31, 2016 at 10:53:02AM -0700, bsegall@...gle.com wrote:
> Yuyang Du <yuyang.du@...el.com> writes:
>
> > The increased load resolution (fixed point arithmetic range) is
> > unconditionally deactivated with #if 0, so it is effectively broken.
> >
> > But the increased load range is still used somewhere (e.g., in Google),
> > so we keep this feature. The reconciliation is we define
> > CONFIG_CFS_INCREASE_LOAD_RANGE and it depends on FAIR_GROUP_SCHED and
> > 64BIT and BROKEN.
> >
> > Suggested-by: Ingo Molnar <mingo@...nel.org>
> > Signed-off-by: Yuyang Du <yuyang.du@...el.com>
>
> The title of this patch "Remove unconditionally inactive code" is
> misleading since it's more like giving it a CONFIG.
Reasonable argument.
>
> Also as a side note, does anyone remember/have a test for whatever got
> it turned off to begin with, given all the changes in load tracking and
> the load balancer and everything else?
It is this commit that turned it off:
Commit e4c2fb0d5776: "sched: Disable (revert) SCHED_LOAD_SCALE increase"
Powered by blists - more mailing lists