All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
	vincent.guittot@linaro.org, morten.rasmussen@arm.com,
	Dietmar.Eggemann@arm.com
Subject: Re: [PATCH 5/5] sched/fair: Skip LLC nohz logic for asymmetric systems
Date: Thu, 7 Feb 2019 11:31:26 +0000	[thread overview]
Message-ID: <9b008247-376d-0fbb-900d-033c19a9ba02@arm.com> (raw)
In-Reply-To: <20190207095639.GA32494@hirez.programming.kicks-ass.net>

On 07/02/2019 09:56, Peter Zijlstra wrote:
[...]
>> I'm afraid I don't follow - we don't lose a balance opportunity with the
>> below change (compared to the original patch), do we?
> 
> What if each big/little cluster would have multiple cache domains? Would
> we not want to spread the cache usage inside the big/little resp. ?
> 

Ah I see - somewhat, yes. And we kindof already hit that issue - on
regular big.LITTLE each "cluster" (big & LITTLE) will have their own L2,
but there's no L3 to share. That means

- sd_llc == MC
- sd_asym_cpucapacity == DIE

(which I believe is what you meant by sd_llc_shared < sd_asym_capacity)

However the LLC nohz kick condition is way too broad and will keep kicking
if we just have 2 busy LITTLEs with 1 task each, which could be a correct
placement if they were just running some small background task.

I'd argue that since we don't have SMT, <=1 task per CPU means we can't do
anything better to spread cache use within the "cluster", and we have to
rely on the other conditions (mostly rq->nr_running and misfit) to move
things around when we really need to.

The extra kicks are there on non asymmetric topologies as well, so we could
imagine an additional gate for the LLC kick that would look like:

  /* If SMT, <=1 task per CPU can be suboptimal
   * If we have a parent (and thus a sibling), we may need to move some tasks to
   * our sibling.
   * If we have asymmetry, asymmetric placement can be fine so just rely on the
   * other kick conditions
   */
  if (static_key_likely(&sched_smt_present) ||
      (!static_key_unlikely(&sched_asym_cpucapacity) && sd->parent)) {
	  // LLC kick stuff here
  }

but I'd argue the extra nohz kicks have more impact on asymmetric systems.

  reply	other threads:[~2019-02-07 11:31 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 15:34 [PATCH 0/5] sched/fair: NOHZ cleanups and misfit improvement Valentin Schneider
2019-01-17 15:34 ` [PATCH 1/5] sched/fair: Use for_each_cpu_and for asym-packing nohz kicks Valentin Schneider
2019-02-11 10:50   ` [tip:sched/core] sched/fair: Simplify nohz_balancer_kick() tip-bot for Valentin Schneider
2019-01-17 15:34 ` [PATCH 2/5] sched/fair: Explain LLC nohz kick condition Valentin Schneider
2019-02-11 10:51   ` [tip:sched/core] " tip-bot for Valentin Schneider
2019-01-17 15:34 ` [PATCH 3/5] sched/fair: Prune nohz_balancer_kick() comment block Valentin Schneider
2019-02-11 10:51   ` [tip:sched/core] sched/fair: Prune, fix and simplify the " tip-bot for Valentin Schneider
2019-01-17 15:34 ` [PATCH 4/5] sched/fair: Tune down misfit nohz kicks Valentin Schneider
2019-02-06 16:04   ` Peter Zijlstra
2019-02-06 17:25     ` Valentin Schneider
2019-02-07  9:57       ` Peter Zijlstra
2019-01-17 15:34 ` [PATCH 5/5] sched/fair: Skip LLC nohz logic for asymmetric systems Valentin Schneider
2019-02-06 16:14   ` Peter Zijlstra
2019-02-06 17:26     ` Valentin Schneider
2019-02-07  9:56       ` Peter Zijlstra
2019-02-07 11:31         ` Valentin Schneider [this message]
2019-02-06 14:33 ` [PATCH 0/5] sched/fair: NOHZ cleanups and misfit improvement Valentin Schneider

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=9b008247-376d-0fbb-900d-033c19a9ba02@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=Dietmar.Eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --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.