public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Pingfan Liu <piliu@redhat.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Cc: Pingfan Liu <piliu@redhat.com>, Waiman Long <longman@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Pierre Gondois <pierre.gondois@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Baoquan He <bhe@redhat.com>, Ingo Molnar <mingo@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Valentin Schneider <vschneid@redhat.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Joel Granados <joel.granados@kernel.org>
Subject: Re: [RFC 2/3] kernel/cpu: Mark nonboot cpus as inactive when shutting down nonboot cpus
Date: Mon, 27 Oct 2025 18:06:32 +0100	[thread overview]
Message-ID: <877bwgw9yf.ffs@tglx> (raw)
In-Reply-To: <20251022121345.23496-3-piliu@redhat.com>

On Wed, Oct 22 2025 at 20:13, Pingfan Liu wrote:
> The previous patch lifted the deadline bandwidth check during the kexec

Once this is applied 'The previous patch' is meaningless.

> process, which raises a potential issue: as the number of online CPUs
> decreases, DL tasks may be crowded onto a few CPUs, which may starve the
> CPU hotplug kthread. As a result, the hot-removal cannot proceed in
> practice.  On the other hand, as CPUs are offlined one by one, all tasks
> will eventually be migrated to the kexec CPU.
>
> Therefore, this patch marks all other CPUs as inactive to signal the

git grep "This patch" Documentation/process/

> scheduler to migrate tasks to the kexec CPU during hot-removal.

I'm not seeing what this solves. It just changes the timing of moving
tasks off to the boot CPU where they compete for the CPU for nothing.

When kexec() is in progress, then running user space tasks at all is a
completely pointless exercise.

So the obvious solution to the problem is to freeze all user space tasks
when kexec() is invoked. No horrible hacks in the deadline scheduler and
elsewhere required to make that work. No?

Thanks,

        tglx

  reply	other threads:[~2025-10-27 17:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-22 12:13 [RFC 0/3] kexec: Force kexec to proceed under heavy deadline load Pingfan Liu
2025-10-22 12:13 ` [RFC 1/3] sched/deadline: Skip the deadline bandwidth check if kexec_in_progress Pingfan Liu
2025-10-22 12:13 ` [RFC 2/3] kernel/cpu: Mark nonboot cpus as inactive when shutting down nonboot cpus Pingfan Liu
2025-10-27 17:06   ` Thomas Gleixner [this message]
2025-10-28  2:51     ` Pingfan Liu
2025-10-28 12:59       ` Thomas Gleixner
2025-10-29 11:36         ` Pingfan Liu
2025-10-29 12:13           ` Thomas Gleixner
2025-10-29 13:39             ` Pingfan Liu
2025-10-22 12:13 ` [RFC 3/3] kexec_core: Promote the kexec to DL task Pingfan Liu

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=877bwgw9yf.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joel.granados@kernel.org \
    --cc=juri.lelli@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pierre.gondois@arm.com \
    --cc=piliu@redhat.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rostedt@goodmis.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox