All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriele Monaco <gmonaco@redhat.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Anna-Maria Behnsen <anna-maria@linutronix.de>,
	 Thomas Gleixner <tglx@linutronix.de>,
	Waiman Long <longman@redhat.com>
Subject: Re: [PATCH v11 8/8] timers: Exclude isolated cpus from timer migration
Date: Tue, 02 Sep 2025 13:08:25 +0200	[thread overview]
Message-ID: <ab9348b0e67f36dea92922bf76aadb7fe9d1667a.camel@redhat.com> (raw)
In-Reply-To: <aLYMA8niL9Uxhu7G@pavilion.home>

On Mon, 2025-09-01 at 23:11 +0200, Frederic Weisbecker wrote:
> Le Mon, Sep 01, 2025 at 03:48:15PM +0200, Gabriele Monaco a écrit :
> > On Mon, 2025-09-01 at 14:41 +0200, Frederic Weisbecker wrote:
> > > Why not evaluate tick_nohz_cpu_hotpluggable() from
> > > tmigr_clear_cpu_available() instead of this force IPI?
> > 
> > The idea is that this IPI runs once during late boot only for the
> > tick CPU, while the call to tick_nohz_cpu_hotpluggable() would be
> > running at every hotplug event if I move it to
> > tmigr_clear_cpu_available. In that scenario, it's guaranteed to
> > return true (besides the very first call).
> > 
> > I don't have a strong opinion against running that check every time
> > although it's needed only at boot time and remove this IPI, but in
> > my understanding that's one of the thing Thomas was finding
> > confusing [1].
> > 
> > Am I missing anything here?
> 
> Right, Thomas didn't like it, but the organization of the code has
> changed a bit since then with the late initcall. If the best we can
> do to workaround the situation is to make the CPU unavailable
> regardless and then undo that right after with an IPI, then it's a
> good sign that we should just simplify and eventually check
> tick_nohz_cpu_hotpluggable() from tmigr_is_isolated().

Makes sense.
I'd be tempted using a static branch but since the call to
tick_nohz_cpu_hotpluggable() isn't really heavy, we can just be fine
including it in the tmigr_is_isolated() check.


> > > But if I understand correctly, this will be handled by cpuset,
> > > right?
> > 
> > Currently tick_nohz_cpu_hotpluggable() is called by
> > tmigr_should_isolate_cpu() and that is called by cpuset code,
> > changing cpuset would save that call but won't deal with the tick
> > CPU not enabled at boot time, unless I'm misunderstanding what
> > Waiman implied.
> 
> Good point!

Here I'm a bit unsure how to proceed though. We want to fail any single
isolated cpuset that includes the tick CPU under nohz_full. I can do it
directly in isolcpus_nohz_conflict and that looks easy.

But is that going to be clear for the user?
Can the user even know what the tick CPU is? Besides /assuming/ 0.

Thanks,
Gabriele

> Thanks.
> 
> > 
> > Thanks,
> > Gabriele
> > 
> > [1] - https://lore.kernel.org/lkml/875xgqqrel.ffs@tglx
> > 


  reply	other threads:[~2025-09-02 11:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-08 16:01 [PATCH v11 0/8] timers: Exclude isolated cpus from timer migration Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 1/8] timers/migration: Postpone online/offline callbacks registration to late initcall Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 2/8] timers: Rename tmigr 'online' bit to 'available' Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 3/8] timers: Add the available mask in timer migration Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 4/8] timers: Use scoped_guard when setting/clearing the tmigr available flag Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 5/8] cgroup/cpuset: Rename update_unbound_workqueue_cpumask() to update_exclusion_cpumasks() Gabriele Monaco
2025-08-08 16:01 ` [PATCH v11 6/8] sched/isolation: Force housekeeping if isolcpus and nohz_full don't leave any Gabriele Monaco
2025-08-12 15:29   ` Waiman Long
2025-09-02 12:19   ` Frederic Weisbecker
2025-08-08 16:01 ` [PATCH v11 7/8] cgroup/cpuset: Fail if isolated and nohz_full don't leave any housekeeping Gabriele Monaco
2025-08-12 15:40   ` Waiman Long
2025-08-12 16:41   ` Waiman Long
2025-08-08 16:01 ` [PATCH v11 8/8] timers: Exclude isolated cpus from timer migration Gabriele Monaco
2025-08-12 17:20   ` Waiman Long
2025-08-13 15:20     ` Gabriele Monaco
2025-09-01 12:41   ` Frederic Weisbecker
2025-09-01 13:48     ` Gabriele Monaco
2025-09-01 21:11       ` Frederic Weisbecker
2025-09-02 11:08         ` Gabriele Monaco [this message]
2025-09-02 12:45           ` Frederic Weisbecker
2025-09-08  8:35             ` Gabriele Monaco
2025-08-27 19:52 ` [PATCH v11 0/8] " John B. Wyatt IV

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=ab9348b0e67f36dea92922bf76aadb7fe9d1667a.camel@redhat.com \
    --to=gmonaco@redhat.com \
    --cc=anna-maria@linutronix.de \
    --cc=frederic@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=tglx@linutronix.de \
    /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.