mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Yury Norov <ynorov@nvidia.com>
To: Fushuai Wang <fushuai.wang@linux.dev>
Cc: agordeev@linux.ibm.com, arighi@nvidia.com,
	borntraeger@linux.ibm.com, bsegall@google.com, corbet@lwn.net,
	dakr@kernel.org, dietmar.eggemann@arm.com,
	driver-core@lists.linux.dev, gor@linux.ibm.com,
	gregkh@linuxfoundation.org, hca@linux.ibm.com, johan@kernel.org,
	juri.lelli@redhat.com, kprateek.nayak@amd.com,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-s390@vger.kernel.org, linux@rasmusvillemoes.dk,
	meted@linux.ibm.com, mgorman@suse.de, mingo@redhat.com,
	peterz@infradead.org, rafael@kernel.org, rdunlap@infradead.org,
	rostedt@goodmis.org, skhan@linuxfoundation.org,
	sshegde@linux.ibm.com, svens@linux.ibm.com, tglx@kernel.org,
	vincent.guittot@linaro.org, vschneid@redhat.com,
	yury.norov@gmail.com
Subject: Re: [PATCH 3/6] sched: Restore preferred CPUs when hotplug removes the last one
Date: Thu, 5 Nov 2026 08:27:16 -0500	[thread overview]
Message-ID: <auyENJOMktDe0uP9@yury> (raw)
In-Reply-To: <20261105090505.93940-1-fushuai.wang@linux.dev>

On Thu, Nov 05, 2026 at 05:05:05PM +0800, Fushuai Wang wrote:
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index 04b62c16fa8c..98f4f9434965 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -8712,6 +8712,14 @@ int sched_cpu_deactivate(unsigned int cpu)
> >  
> >  	set_cpu_active(cpu, false);
> >  
> > +#ifdef CONFIG_PREFERRED_CPU
> > +	if (cpumask_empty(cpu_preferred_mask)) {
> > +		pr_notice("sched: last preferred CPU%u offlined; make all active CPUs preferred\n",
> > +			  cpu);
> > +		reset_preferred_cpumask();
> 
> Hi, Yury
> 
> If the CPU being offlined is the only preferred CPU, after
> reset_preferred_cpumask(), the steal governor may still need
> some time to tighten the mask again, and eventually only one
> preferred CPU may remain. Would this introduce additional
> task migration overhead?

This is the safest fallback from the scheduler POV. Current steal
governor implementation would require multiple iterations to get back
to the old equilibrium. If it will show up as a real problem, we can
teach steal governor to converge faster, and/or detect the preferred
mask reset.

Thanks,
Yury

  reply	other threads:[~2026-11-05 13:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-01 19:21 [PATCH 0/6] sched: Expose writable interface for preferred CPUs mask Yury Norov
2026-11-01 19:21 ` [PATCH 1/6] sched: decouple PREFERRED_CPU from PARAVIRT in Kconfig.preempt Yury Norov
2026-11-02 10:16   ` Ilya Leoshkevich
2026-11-02 11:00     ` Peter Zijlstra
2026-11-02 11:34       ` Ilya Leoshkevich
2026-11-02 13:00         ` Shrikanth Hegde
2026-11-02 13:41           ` Ilya Leoshkevich
2026-11-02 14:57             ` Shrikanth Hegde
2026-11-03  5:49             ` Shrikanth Hegde
2026-11-03 11:26               ` Ilya Leoshkevich
2026-11-03 11:30                 ` Ilya Leoshkevich
2026-11-01 19:21 ` [PATCH 2/6] cpumask: Add reset_preferred_cpumask() helper Yury Norov
2026-11-01 19:21 ` [PATCH 3/6] sched: Restore preferred CPUs when hotplug removes the last one Yury Norov
2026-11-05  9:05   ` Fushuai Wang
2026-11-05 13:27     ` Yury Norov [this message]
2026-11-01 19:22 ` [PATCH 4/6] sched: serialize preferred cpumask update better Yury Norov
2026-11-01 19:22 ` [PATCH 5/6] virt: steal_governor: Warn on unexpected preferred mask states Yury Norov
2026-11-01 19:22 ` [PATCH 6/6] cpu: Add per-CPU preferred sysfs control Yury Norov
2026-11-02  8:47 ` [PATCH 0/6] sched: Expose writable interface for preferred CPUs mask Peter Zijlstra
2026-11-03 16:49   ` Yury Norov
2026-11-05 14:55     ` Peter Zijlstra

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=auyENJOMktDe0uP9@yury \
    --to=ynorov@nvidia.com \
    --cc=agordeev@linux.ibm.com \
    --cc=arighi@nvidia.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=bsegall@google.com \
    --cc=corbet@lwn.net \
    --cc=dakr@kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=driver-core@lists.linux.dev \
    --cc=fushuai.wang@linux.dev \
    --cc=gor@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hca@linux.ibm.com \
    --cc=johan@kernel.org \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=meted@linux.ibm.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael@kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=skhan@linuxfoundation.org \
    --cc=sshegde@linux.ibm.com \
    --cc=svens@linux.ibm.com \
    --cc=tglx@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=yury.norov@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®