All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Valentin Schneider <valentin.schneider@arm.com>
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 10:56:39 +0100	[thread overview]
Message-ID: <20190207095639.GA32494@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <5010b09f-6954-fda6-a10f-a8aa05806866@arm.com>

On Wed, Feb 06, 2019 at 05:26:06PM +0000, Valentin Schneider wrote:
> Hi,
> 
> On 06/02/2019 16:14, Peter Zijlstra wrote:
> [...]
> >> @@ -9545,6 +9545,17 @@ static void nohz_balancer_kick(struct rq *rq)
> >>  	}
> >>  
> >>  	rcu_read_lock();
> >> +
> >> +	if (static_branch_unlikely(&sched_asym_cpucapacity))
> >> +		/*
> >> +		 * For asymmetric systems, we do not want to nicely balance
> >> +		 * cache use, instead we want to embrace asymmetry and only
> >> +		 * ensure tasks have enough CPU capacity.
> >> +		 *
> >> +		 * Skip the LLC logic because it's not relevant in that case.
> >> +		 */
> >> +		goto check_capacity;
> >> +
> >>  	sds = rcu_dereference(per_cpu(sd_llc_shared, cpu));
> >>  	if (sds) {
> >>  		/*
> > 
> > Since (before this) the actual order of the various tests doesn't
> > matter, it's a logical cascade of conditions for which to KICK_MASK.
> > 
> 
> Ah, I assumed the order did matter somewhat with the "cheaper" LLC check
> first and the more costly loops further down in case we are still looking
> for a reason to do a kick.

I did not in fact consider that; I only looked at the logical structure
of the thing. You might want to double check :-)

> > We can easily reorder and short-circuit the cascase like so, no?
> > 
> > The only concern is if sd_llc_shared < sd_asym_capacity; in which case
> > we just lost a balance opportunity. Not sure how to best retain that
> > though.
> > 
> 
> 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. ?

  reply	other threads:[~2019-02-07  9:56 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 [this message]
2019-02-07 11:31         ` Valentin Schneider
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=20190207095639.GA32494@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Dietmar.Eggemann@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=morten.rasmussen@arm.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.