All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org,
	Michael Ellerman <mpe@ellerman.id.au>,
	Madhavan Srinivasan <maddy@linux.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, Ben Segall <bsegall@google.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>, Mel Gorman <mgorman@suse.de>,
	Nicholas Piggin <npiggin@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Valentin Schneider <vschneid@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: [PATCH 1/2] sched: Feature to decide if steal should update CPU capacity
Date: Tue, 28 Oct 2025 17:12:07 +0530	[thread overview]
Message-ID: <aQCsD4AWgjczDfjB@linux.ibm.com> (raw)
In-Reply-To: <20251028111813.GK3245006@noisy.programming.kicks-ass.net>

* Peter Zijlstra <peterz@infradead.org> [2025-10-28 12:18:13]:

> On Tue, Oct 28, 2025 at 04:12:54PM +0530, Srikar Dronamraju wrote:
> > At present, scheduler scales CPU capacity for fair tasks based on time
> > spent on irq and steal time. If a CPU sees irq or steal time, its
> > capacity for fair tasks decreases causing tasks to migrate to other CPU
> > that are not affected by irq and steal time. All of this is gated by
> > NONTASK_CAPACITY.
> > 
> > In virtualized setups, a CPU that reports steal time (time taken by the
> > hypervisor) can cause tasks to migrate unnecessarily to sibling CPUs that
> > appear to be less busy, only for the situation to reverse shortly.
> > 
> > To mitigate this ping-pong behaviour, this change introduces a new
> > scheduler feature flag: ACCT_STEAL which will control whether steal time
> > contributes to non-task capacity adjustments (used for fair scheduling).
> 
> Please don't use sched_feat like this. If this is something that wants
> to be set by architectures move it to a normal static_branch (like eg.
> sched_energy_present, sched_asymc_cpucapacity, sched_cluster_active,
> sched_smt_present, sched_numa_balancing etc.).

Ok, Peter, will move it to a static_branch approach and post a v2.

-- 
Thanks and Regards
Srikar Dronamraju


  reply	other threads:[~2025-10-28 11:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-28 10:42 [PATCH 1/2] sched: Feature to decide if steal should update CPU capacity Srikar Dronamraju
2025-10-28 10:42 ` [PATCH 2/2] powerpc/smp: Disable ACCT_STEAL for shared LPARs Srikar Dronamraju
2025-10-28 11:18 ` [PATCH 1/2] sched: Feature to decide if steal should update CPU capacity Peter Zijlstra
2025-10-28 11:42   ` Srikar Dronamraju [this message]
2025-10-28 15:05 ` Shrikanth Hegde
2025-10-29  6:08   ` K Prateek Nayak

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=aQCsD4AWgjczDfjB@linux.ibm.com \
    --to=srikar@linux.ibm.com \
    --cc=bsegall@google.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.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 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.