From: Peter Zijlstra <peterz@infradead.org>
To: Mel Gorman <mgorman@techsingularity.net>
Cc: "Li, Aubrey" <aubrey.li@linux.intel.com>,
mingo@redhat.com, juri.lelli@redhat.com,
vincent.guittot@linaro.org, valentin.schneider@arm.com,
qais.yousef@arm.com, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com,
tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org,
Mel Gorman <mgorman@suse.de>, Jiang Biao <benbjiang@gmail.com>
Subject: Re: [RFC PATCH v7] sched/fair: select idle cpu from idle cpumask for task wakeup
Date: Mon, 14 Dec 2020 10:32:07 +0100 [thread overview]
Message-ID: <20201214093207.GY3040@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20201211225002.GY3371@techsingularity.net>
On Fri, Dec 11, 2020 at 10:50:02PM +0000, Mel Gorman wrote:
> > > The third potential downside is that the SMT sibling is not guaranteed to
> > > be checked due to SIS_PROP throttling but in the old code, that would have
> > > been checked by select_idle_smt(). That might result in premature stacking
> > > of runnable tasks on the same CPU. Similarly, as __select_idle_core may
> > > find multiple idle candidates, it will not pick the targets SMT sibling
> > > if it is idle like select_idle_smt would have.
> > >
> > > That said, I am skeptical that select_idle_smt() matters all that often.
> >
> > This, I didn't really believe in it either.
> >
>
> Good because I think any benefit from select_idle_smt is so marginal
> that it should be ignored if the full scan is simpler overall.
Perhaps we should start out with a simple patch removing that pass..
That should show, what, if anything, the effect of it is.
next prev parent reply other threads:[~2020-12-14 9:33 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 6:24 [RFC PATCH v7] sched/fair: select idle cpu from idle cpumask for task wakeup Aubrey Li
2020-12-09 8:15 ` Vincent Guittot
2020-12-09 10:58 ` Li, Aubrey
2020-12-09 13:09 ` Vincent Guittot
2020-12-09 14:53 ` Li, Aubrey
2020-12-09 14:36 ` Mel Gorman
2020-12-10 8:23 ` Li, Aubrey
2020-12-10 11:34 ` Mel Gorman
2020-12-10 12:21 ` Li, Aubrey
2020-12-10 12:58 ` Mel Gorman
2020-12-11 17:44 ` Peter Zijlstra
2020-12-11 20:43 ` Mel Gorman
2020-12-11 22:19 ` Peter Zijlstra
2020-12-11 22:50 ` Mel Gorman
2020-12-14 8:11 ` Vincent Guittot
2020-12-14 9:31 ` Peter Zijlstra
2020-12-14 12:36 ` Mel Gorman
2020-12-14 15:01 ` Peter Zijlstra
2020-12-14 9:32 ` Peter Zijlstra [this message]
2020-12-14 9:18 ` Vincent Guittot
2020-12-14 12:42 ` Mel Gorman
2020-12-14 7:53 ` Li, Aubrey
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=20201214093207.GY3040@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aubrey.li@linux.intel.com \
--cc=benbjiang@gmail.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=qais.yousef@arm.com \
--cc=rostedt@goodmis.org \
--cc=tim.c.chen@linux.intel.com \
--cc=valentin.schneider@arm.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 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.