All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Fengguang Wu <fengguang.wu@intel.com>,
	Li Zhijian <zhijianx.li@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/fair: Disable LB_BIAS by default
Date: Tue, 11 Sep 2018 08:22:49 +0200	[thread overview]
Message-ID: <20180911062249.GD72017@gmail.com> (raw)
In-Reply-To: <20180910141205.GM24106@hirez.programming.kicks-ass.net>


* Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, Aug 09, 2018 at 02:57:53PM +0100, Dietmar Eggemann wrote:
> > LB_BIAS allows the adjustment on how conservative load should be
> > balanced.
> 
> > It is very likely that LB_BIAS' influence on load balancing can be
> > neglected (see test results below). This is further supported by:
> > 
> > (1) Weighted CPU load today is by itself a decayed average value (PELT)
> >     (cfs_rq->avg->runnable_load_avg) and not the instantaneous load
> >     (rq->load.weight) it was when LB_BIAS was introduced.
> > 
> > (2) Sd imbalance_pct is used for CPU_NEWLY_IDLE and CPU_NOT_IDLE (relate
> >     to sd's newidle and busy idx) in find_busiest_group() when comparing
> >     busiest and local avg load to make load balancing even more
> >     conservative.
> > 
> > (3) The sd forkexec and newidle idx are always set to 0 so there is no
> >     adjustment on how conservatively load balancing is done here.
> > 
> > (4) Affine wakeup based on weight (wake_affine_weight()) will not be
> >     impacted since the sd wake idx is always set to 0.
> > 
> > Let's disable LB_BIAS by default for a few kernel releases to make sure
> > that no workload and no scheduler topology is affected. The benefit of
> > being able to remove the LB_BIAS dependency from source_load() and
> > target_load() is that the entire rq->cpu_load[idx] code could be removed
> > in this case.
> 
> Certainly worth a try; as I've written somewhere in a comment; it would
> be very nice to get rid of that load tracking crud.
> 
> And it is trivial to revert if something does show up.
> 
> Ingo, what do you think?

Ack, I'm very much in favor of reducing complexity.

Thanks,

	Ingo

  reply	other threads:[~2018-09-11  6:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-09 13:57 [PATCH] sched/fair: Disable LB_BIAS by default Dietmar Eggemann
2018-09-10 14:12 ` Peter Zijlstra
2018-09-11  6:22   ` Ingo Molnar [this message]
2018-09-11 11:30     ` Peter Zijlstra
2018-10-02 10:06 ` [tip:sched/core] " tip-bot for Dietmar Eggemann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180911062249.GD72017@gmail.com \
    --to=mingo@kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=fengguang.wu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=zhijianx.li@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.