All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: Christian Loehle <christian.loehle@arm.com>,
	peterz@infradead.org, dietmar.eggemann@arm.com,
	valentin.schneider@arm.com, mingo@redhat.com,
	rostedt@goodmis.org, segall@google.com, mgorman@suse.de,
	catalin.marinas@arm.com, will@kernel.org, sudeep.holla@arm.com,
	rafael@kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org, juri.lelli@redhat.com,
	kobak@nvidia.com, fabecassis@nvidia.com
Subject: Re: [RFC][RFT][PATCH 0/3] arm64: Enable asympacking for minor CPPC asymmetry
Date: Thu, 26 Mar 2026 10:15:50 +0100	[thread overview]
Message-ID: <acT5RjFefzQrkxHW@gpd4> (raw)
In-Reply-To: <CAKfTPtDmnnGONJhrQPNh2rhe3-KvMkX1nW8-JYN+otNLQYSU-w@mail.gmail.com>

On Thu, Mar 26, 2026 at 09:20:45AM +0100, Vincent Guittot wrote:
> On Thu, 26 Mar 2026 at 09:12, Andrea Righi <arighi@nvidia.com> wrote:
> >
> > Hi Christian,
> >
> > On Wed, Mar 25, 2026 at 06:13:11PM +0000, Christian Loehle wrote:
> > ...
> > > RFT:
> > > Andrea, please give this a try. This should perform better in particular
> > > for single-threaded workloads and workloads that do not utilize all
> > > cores (all the time anyway).
> > > Capacity-aware scheduling wakeup works very different to the SMP path
> > > used now, some workloads will benefit, some regress, it would be nice
> > > to get some test results for these.
> > > We already discussed DCPerf MediaWiki seems to benefit from
> > > capacity-aware scheduling wakeup behavior, but others (most?) should
> > > benefit from this series.
> > >
> > > I don't know if we can also be clever about ordering amongst SMT siblings.
> > > That would be dependent on the uarch and I don't have a platform to
> > > experiment with this though, so consider this series orthogonal to the
> > > idle-core SMT considerations.
> > > On platforms with SMT though asympacking makes a lot more sense than
> > > capacity-aware scheduling, because arguing about capacity without
> > > considering utilization of the sibling(s) (and the resulting potential
> > > 'stolen' capacity we perceive) isn't theoretically sound.
> >
> > I did some early testing with this patch set. On Vera I'm getting much
> > better performance that SD_ASYM_CPUCAPACITY of course (~1.5x avg speedup),
> > mostly because we avoid using both SMT siblings. It's still not the same
> > improvement that I get equalizing the capacity using the 5% threshold
> > (~1.8x speedup).
> 
> IIRC the tests that you shared in your patch, you get an additonal
> improvement when adding some SMT awarness to SD_ASYM_CPUCAPACITY
> compared to equalizing the capacity

Yes, adding SMT awareness to SD_ASYM_CPUCAPACITY is still the apparoach
that gives me the best performance so far on Vera (~1.9x avg speedup),
among all those that I've tested.

I'll post the updated patch set that I'm using, so we can also elaborate
more on that approach as well.

Thanks,
-Andrea

      reply	other threads:[~2026-03-26  9:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-25 18:13 [RFC][RFT][PATCH 0/3] arm64: Enable asympacking for minor CPPC asymmetry Christian Loehle
2026-03-25 18:13 ` [PATCH 1/3] sched/topology: Introduce arch hooks for asympacking Christian Loehle
2026-03-26 13:23   ` kernel test robot
2026-03-26 15:26   ` kernel test robot
2026-03-26 16:40   ` kernel test robot
2026-03-25 18:13 ` [PATCH 2/3] arch_topology: Export CPPC-based asympacking prios Christian Loehle
2026-03-25 18:13 ` [PATCH 3/3] arm64/sched: Enable CPPC-based asympacking Christian Loehle
2026-03-26 15:47   ` kernel test robot
2026-03-26 15:47   ` kernel test robot
2026-03-27 15:44   ` Valentin Schneider
2026-03-29 17:49     ` Christian Loehle
2026-03-26  7:53 ` [RFC][RFT][PATCH 0/3] arm64: Enable asympacking for minor CPPC asymmetry Vincent Guittot
2026-03-26  8:16   ` Christian Loehle
2026-03-26  8:24     ` Vincent Guittot
2026-03-26  9:24       ` Christian Loehle
2026-03-26 13:04         ` Vincent Guittot
2026-03-26 13:45           ` Andrea Righi
2026-03-26 15:55             ` Christian Loehle
2026-03-26 16:00               ` Andrea Righi
2026-03-27  9:53               ` Andrea Righi
2026-03-26  8:20   ` Christian Loehle
2026-03-26  8:11 ` Andrea Righi
2026-03-26  8:20   ` Vincent Guittot
2026-03-26  9:15     ` Andrea Righi [this message]

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=acT5RjFefzQrkxHW@gpd4 \
    --to=arighi@nvidia.com \
    --cc=catalin.marinas@arm.com \
    --cc=christian.loehle@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=fabecassis@nvidia.com \
    --cc=juri.lelli@redhat.com \
    --cc=kobak@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=segall@google.com \
    --cc=sudeep.holla@arm.com \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.org \
    --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.