From: Peter Zijlstra <peterz@infradead.org>
To: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
Cc: Ingo Molnar <mingo@kernel.org>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.comi>, Mel Gorman <mgorman@suse.de>,
Len Brown <len.brown@intel.com>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Aubrey Li <aubrey.li@linux.intel.com>,
"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
Ricardo Neri <ricardo.neri@intel.com>,
Quentin Perret <qperret@google.com>,
"Joel Fernandes (Google)" <joel@joelfernandes.org>,
linux-kernel@vger.kernel.org, Aubrey Li <aubrey.li@intel.com>,
Ben Segall <bsegall@google.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>
Subject: Re: [PATCH 3/4] sched/fair: Consider SMT in ASYM_PACKING load balance
Date: Thu, 8 Apr 2021 13:10:39 +0200 [thread overview]
Message-ID: <YG7kr0Gyj86sMBF8@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20210406231710.GB27195@ranerica-svr.sc.intel.com>
On Tue, Apr 06, 2021 at 04:17:10PM -0700, Ricardo Neri wrote:
> On Tue, Apr 06, 2021 at 01:17:28PM +0200, Peter Zijlstra wrote:
> > On Mon, Apr 05, 2021 at 09:11:07PM -0700, Ricardo Neri wrote:
> > > @@ -8507,6 +8619,10 @@ static bool update_sd_pick_busiest(struct lb_env *env,
> > > if (!sgs->sum_h_nr_running)
> > > return false;
> > >
> > > + if (sgs->group_type == group_asym_packing &&
> > > + !asym_can_pull_tasks(env->dst_cpu, sds, sgs, sg))
> > > + return false;
> >
> > All of this makes my head hurt; but afaict this isn't right.
> >
> > Your update_sg_lb_stats() change makes that we unconditionally set
> > sgs->group_asym_packing, and then this is to undo that. But it's not
> > clear this covers all cases right.
>
> We could not make a decision to set sgs->group_asym_packing in
> update_sg_lb_stats() because we don't have information about the dst_cpu
> and its SMT siblings if any. That is the reason I proposed to delay the
> decision to update_sd_pick_busiest(), where we can compare local and
> sgs.
Yeah, I sorta got that.
> > Even if !sched_asym_prefer(), we could end up selecting this sg as
> > busiest, but you're just bailing out here.
>
> Even if sgs->group_asym_packing is unconditionally set, sgs can still
> be classified as group_overloaded and group_imbalanced. In such cases
> we wouldn't bailout. sgs could not be classified as group_fully_busy
> or group_has_spare and we would bailout, though. Is your concern about
> these? I can fixup these two cases.
Yes. Either explain (in a comment) why those cases are not relevant, or
handle them properly.
Because when reading this, it wasn't at all obvious that this is correct
or as intended.
next prev parent reply other threads:[~2021-04-08 16:47 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-06 4:11 [PATCH 0/4] sched/fair: Fix load balancing of SMT siblings with ASYM_PACKING Ricardo Neri
2021-04-06 4:11 ` [PATCH 1/4] sched/fair: Optimize checking for group_asym_packing Ricardo Neri
2021-04-06 4:11 ` [PATCH 2/4] sched/fair: Introduce arch_sched_asym_prefer_early() Ricardo Neri
2021-04-06 14:31 ` Vincent Guittot
2021-04-06 23:36 ` Ricardo Neri
2021-04-06 4:11 ` [PATCH 3/4] sched/fair: Consider SMT in ASYM_PACKING load balance Ricardo Neri
2021-04-06 11:17 ` Peter Zijlstra
2021-04-06 23:17 ` Ricardo Neri
2021-04-08 11:10 ` Peter Zijlstra [this message]
2021-04-09 5:12 ` Ricardo Neri
2021-04-06 11:18 ` Peter Zijlstra
2021-04-06 23:17 ` Ricardo Neri
2021-04-08 11:21 ` Peter Zijlstra
2021-04-09 5:13 ` Ricardo Neri
2021-04-06 4:11 ` [PATCH 4/4] x86/sched: Enable checks of the state of SMT siblings in load balancing Ricardo Neri
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=YG7kr0Gyj86sMBF8@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aubrey.li@intel.com \
--cc=aubrey.li@linux.intel.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=bsegall@google.comi \
--cc=dietmar.eggemann@arm.com \
--cc=joel@joelfernandes.org \
--cc=juri.lelli@redhat.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=qperret@google.com \
--cc=ravi.v.shankar@intel.com \
--cc=ricardo.neri-calderon@linux.intel.com \
--cc=ricardo.neri@intel.com \
--cc=rostedt@goodmis.org \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).