All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Andrea Righi <arighi@nvidia.com>, Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Christian Loehle <christian.loehle@arm.com>,
	Shrikanth Hegde <sshegde@linux.ibm.com>,
	Phil Auld <pauld@redhat.com>, Breno Leitao <leitao@debian.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection
Date: Thu, 3 Sep 2026 12:59:59 +0200	[thread overview]
Message-ID: <0d02e284-9a07-4f54-bf63-8edaa5e224e5@arm.com> (raw)
In-Reply-To: <20260831181800.1668646-3-arighi@nvidia.com>

On 31.08.26 20:10, Andrea Righi wrote:
> SD_ASYM_PACKING orders CPUs that share an SMT core, but idle CPU
> selection does not consult that order. A task can therefore wake on an
> arbitrary sibling and remain there until load balancing corrects the
> placement. On SMT implementations where changing the active sibling
> repartitions core resources, that initial choice can cause a large and
> persistent performance loss.

I assume this sentence refers to Olympus/Vera and Power7?

[...]

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 8dff37059faf7..3c49aa63742cb 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -8587,6 +8587,65 @@ static inline bool test_idle_cores(int cpu)
>  	return false;
>  }
>  
> +/*
> + * Return true when @cpu has a higher asymmetric-packing priority than @other in their SMT
> + * scheduling domain.
> + */
> +static bool sched_smt_asym_prefer(int cpu, int other)
> +{
> +	struct sched_domain *sd;
> +
> +	for_each_domain(cpu, sd) {
> +		/*
> +		 * Only honor priorities declared at shared-capacity SMT levels.
> +		 * SD_ASYM_PACKING at higher levels may describe core ordering.
> +		 */
> +		if (!(sd->flags & SD_SHARE_CPUCAPACITY))
> +			break;
> +
> +		if ((sd->flags & SD_ASYM_PACKING) && cpumask_test_cpu(other, sched_domain_span(sd)))

Looks like 'other' is always part of the mask?

> +			return sched_asym_prefer(cpu, other);
> +	}
> +
> +	return false;
> +}

SMT will always the lowest SD, so for_each_domain() is not necessary:

static bool sched_smt_asym_prefer(int cpu, int other)
{
        struct sched_domain *sd = rcu_dereference_all(cpu_rq(cpu)->sd);

        if (sd && ((sd->flags & (SD_SHARE_CPUCAPACITY |
SD_ASYM_PACKING)) == (SD_SHARE_CPUCAPACITY | SD_ASYM_PACKING)))
                return sched_asym_prefer(cpu, other);

        return false;
}

[...]

> @@ -8668,7 +8727,7 @@ static int select_idle_smt(struct task_struct *p, struct sched_domain *sd, int t
>  		if (!cpumask_test_cpu(cpu, sched_domain_span(sd)))
>  			continue;
>  		if (choose_idle_cpu(cpu, p))
> -			return cpu;
> +			return select_idle_smt_priority(p, cpu);

This one is weird for SMT2. AFAICS, select_idle_smt() is called when
there are no idle cores. So if you find an idle CPU this is what you
will return anyway.

I guess your tests on Olympus/Vera do wakeups via select_idle_capacity()
so you haven't touched this one.

[...]


  reply	other threads:[~2026-09-03 11:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 18:10 [PATCH 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-08-31 18:10 ` [PATCH 1/2] arm64: topology: Prefer PE0 on NVIDIA Olympus SMT cores Andrea Righi
2026-08-31 21:13   ` Christian Loehle
2026-08-31 21:43     ` Andrea Righi
2026-09-01  6:05       ` Andrea Righi
2026-09-01  8:32       ` Christian Loehle
2026-09-01 19:38         ` Andrea Righi
2026-08-31 18:10 ` [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-03 10:59   ` Dietmar Eggemann [this message]
2026-09-04  5:59     ` Andrea Righi
  -- strict thread matches above, loose matches on Subject: below --
2026-09-04  9:18 [PATCH v2 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-04  9:18 ` [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-07  3:57   ` K Prateek Nayak
2026-09-07  9:11     ` Andrea Righi
2026-09-07  9:40       ` K Prateek Nayak
2026-09-07  9:50         ` Andrea Righi
2026-09-07 16:48     ` Shrikanth Hegde
2026-09-08  5:37   ` Srikar Dronamraju
2026-09-08  6:12     ` Andrea Righi
2026-09-07 16:30 [PATCH v3 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-07 16:30 ` [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-08  8:23 [PATCH v4 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-08  8:23 ` [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-08 19:40   ` K Prateek Nayak
2026-09-08 20:49     ` Andrea Righi
2026-09-09  6:32       ` K Prateek Nayak
2026-09-09 14:42   ` Vincent Guittot
2026-09-09 15:18     ` Andrea Righi
2026-09-09 15:42       ` Vincent Guittot
2026-09-09 16:22         ` Andrea Righi
2026-09-09  6:26 [PATCH v5 0/2] sched: Enable preferred SMT siblings on NVIDIA Olympus Andrea Righi
2026-09-09  6:26 ` [PATCH 2/2] sched/fair: Honor asymmetric SMT priority in idle selection Andrea Righi
2026-09-11 14:11   ` Dietmar Eggemann
2026-09-11 22:34     ` Andrea Righi

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=0d02e284-9a07-4f54-bf63-8edaa5e224e5@arm.com \
    --to=dietmar.eggemann@arm.com \
    --cc=arighi@nvidia.com \
    --cc=bsegall@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=christian.loehle@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=leitao@debian.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sshegde@linux.ibm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=will@kernel.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.