mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: Qais Yousef <qais.yousef@arm.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.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.com>, Mel Gorman <mgorman@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Yury Norov <yury.norov@gmail.com>, Paul Turner <pjt@google.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Josh Don <joshdon@google.com>,
	Pavan Kondeti <pkondeti@codeaurora.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/4] sched/rt: Distribute tasks in find_lowest_rq()
Date: Tue, 14 Apr 2020 19:58:49 +0100	[thread overview]
Message-ID: <jhjh7xlvqqe.mognet@arm.com> (raw)
In-Reply-To: <20200414150556.10920-1-qais.yousef@arm.com>

Hi,

On 14/04/20 16:05, Qais Yousef wrote:
> Now that we have a proper function that returns a 'random' CPU in a mask [1]
> utilize that in find_lowest_rq() to solve the thundering herd issue described
> in this thread
>
>       https://lore.kernel.org/lkml/20200219140243.wfljmupcrwm2jelo@e107158-lin/
>
> But as a pre-amble, I noticed that the new cpumask_any_and_distribute() is
> actually an alias for cpumask_any_and() which is documented as returning
> a 'random' cpu but actually just does cpumask_first_and().
>
> The first 3 patches cleanup the API so that the whole family of
> cpumask_any*() take advantage of the new 'random' behavior

I'm a bit wary about such blanket changes. I feel like most places impacted
by this change don't gain anything by using the random thing. In sched land
that would be:

- The single cpumask_any() in core.c::select_task_rq()
- Pretty much any function that wants a CPU id to dereference a
  root_domain; there's some of them in deadline.c, topology.c

Looking some more into it, there's shadier things:

- cpufreq_offline() uses cpumask_any() to figure out the new policy
  leader... That one should be cpumask_first()
- gic_set_affinity() uses cpumask_any_and() (in the common case). If this
  starts using randomness, you will stop affining e.g. all SPIs to CPU0
  by default (!!!)
- ... and there might be more

I think people went with cpumask_any_* mostly because there is just
cpumask_first() while there are more cpumask_any_* variants, and since
those have been returning the first set CPU for over a decade people just
went with it.

To move this forward, I would suggest renaming the current cpumask_any_*()
into cpumask_first_*(), and THEN introduce the new pseudo-random
ones. People are then free to hand-fix specific locations if it makes sense
there, like you're doing for RT.

I think it's safe to say the vast majority of the current callers do not
require randomness - the exceptions should mainly be scheduler / workqueues
and the like.

> and in patch
> 4 I convert the cpumask_first_and() --> cpumask_any_and() in find_lowest_rq()
> to allow to better distribute the RT tasks that wake up simultaneously.
>
> [1] https://lore.kernel.org/lkml/20200311010113.136465-1-joshdon@google.com/
>
> CC: Juri Lelli <juri.lelli@redhat.com>
> CC: Vincent Guittot <vincent.guittot@linaro.org>
> CC: Dietmar Eggemann <dietmar.eggemann@arm.com>
> CC: Steven Rostedt <rostedt@goodmis.org>
> CC: Ben Segall <bsegall@google.com>
> CC: Mel Gorman <mgorman@suse.de>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: Yury Norov <yury.norov@gmail.com>
> CC: Paul Turner <pjt@google.com>
> CC: Alexey Dobriyan <adobriyan@gmail.com>
> CC: Josh Don <joshdon@google.com>
> CC: Pavan Kondeti <pkondeti@codeaurora.org>
> CC: linux-kernel@vger.kernel.org
>
> Qais Yousef (4):
>   cpumask: Rename cpumask_any_and_distribute
>   cpumask: Make cpumask_any() truly random
>   cpumask: Convert cpumask_any_but() to the new random function
>   sched/rt: Better distribute tasks that wakeup simultaneously
>
>  include/linux/cpumask.h | 33 ++++++-----------
>  kernel/sched/core.c     |  2 +-
>  kernel/sched/rt.c       |  4 +-
>  lib/cpumask.c           | 82 +++++++++++++++++++++++++++--------------
>  4 files changed, 68 insertions(+), 53 deletions(-)

  parent reply	other threads:[~2020-04-14 18:59 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-14 15:05 Qais Yousef
2020-04-14 15:05 ` [PATCH 1/4] cpumask: Rename cpumask_any_and_distribute Qais Yousef
2020-04-14 15:05 ` [PATCH 2/4] cpumask: Make cpumask_any() truly random Qais Yousef
2020-04-14 16:19   ` Steven Rostedt
2020-04-15  9:36     ` Peter Zijlstra
2020-04-20 15:43       ` Qais Yousef
2020-04-20 21:36         ` Josh Don
2020-05-28  8:52   ` [cpumask] a7934287d8: BUG:using__this_cpu_read()in_preemptible[#]code:kworker kernel test robot
2020-04-14 15:05 ` [PATCH 3/4] cpumask: Convert cpumask_any_but() to the new random function Qais Yousef
2020-04-14 16:28   ` Steven Rostedt
2020-04-20 15:49     ` Qais Yousef
2020-04-14 15:05 ` [PATCH 4/4] sched/rt: Better distribute tasks that wakeup simultaneously Qais Yousef
2020-04-14 18:58 ` Valentin Schneider [this message]
2020-04-14 20:27   ` [PATCH 0/4] sched/rt: Distribute tasks in find_lowest_rq() Steven Rostedt
2020-04-14 20:56     ` Valentin Schneider
2020-04-15  9:39     ` Peter Zijlstra
2020-04-15 13:18       ` Steven Rostedt
2020-04-21 12:15       ` Qais Yousef
2020-04-21 12:13   ` Qais Yousef
2020-04-21 13:18     ` Valentin Schneider
2020-04-21 13:28       ` Vincent Guittot
2020-04-21 14:22         ` Yury Norov
2020-04-21 14:25         ` Qais Yousef
2020-04-21 14:09       ` Marc Zyngier
2020-04-21 14:22         ` Qais Yousef
2020-04-21 14:28           ` Marc Zyngier
2020-04-21 14:39             ` Qais Yousef

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=jhjh7xlvqqe.mognet@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joshdon@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=pkondeti@codeaurora.org \
    --cc=qais.yousef@arm.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=vincent.guittot@linaro.org \
    --cc=yury.norov@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome