linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gabriele Monaco <gmonaco@redhat.com>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	 Waiman Long <longman@redhat.com>,
	Anna-Maria Behnsen <anna-maria@linutronix.de>
Subject: Re: [PATCH v5 5/6] cgroup/cpuset: Fail if isolated and nohz_full don't leave any housekeeping
Date: Fri, 23 May 2025 13:15:44 +0200	[thread overview]
Message-ID: <3acad4a1a07ccbde615ea19eb13a96f37d4a3a2f.camel@redhat.com> (raw)
In-Reply-To: <aCyRhAeGwLSVf2LZ@localhost.localdomain>

On Tue, 2025-05-20 at 16:28 +0200, Frederic Weisbecker wrote:
> 
> Apparently you can't trigger the same with isolcpus=0-6, for some
> reason.
> 
> One last thing, nohz_full makes sure that we never offline the
> timekeeper
> (see tick_nohz_cpu_down()). The timekeeper also never shuts down its
> tick
> and therefore never go idle, from tmigr perspective, this way when a
> nohz_full
> CPU shuts down its tick, it makes sure that its global timers are
> handled by
> the timekeeper in last resort, because it's the last global migrator,
> always
> alive.
> 
> But if the timekeeper is HK_TYPE_DOMAIN, or isolated by cpuset, it
> will go out
> of the tmigr hierarchy, breaking the guarantee to have a live global
> migrator
> for nohz_full.
> 
> That one is a bit more tricky to solve. The easiest is to forbid the
> timekeeper
> from ever being made unavailable. It is also possible to migrate the
> timekeeping duty
> to another common housekeeper.
> 
> We probably need to do the latter...

I'm thinking about this again, is it really worth the extra complexity?

The tick CPU is already set as the boot CPU and if the user requests it
as nohz_full, that's not accepted.
In my understanding, this typically happens on CPU0 and this CPU is
kinda special and is advised to stay as housekeeping. As far as I
understand, when nohz_full is enabled, the tick CPU cannot change.

Said that, I'd reconsider force keeping the tick CPU in the hierarchy
no matter if we isolate it or not when nohz_full is active (e.g. what
you mentioned as the /easy/ way).
We'd not prevent domain isolation (as the user requested), but allow a
bit more noise just on that CPU for the sake of keeping things simple
while not falling into dangerous corner cases.
If that's still a problem for the user, they are probably better off
either selecting a different mask or setting nohz_full consistently
(I'm still wondering how common a scenario this is).

Am I missing something here?

Thanks,
Gabriele


  parent reply	other threads:[~2025-05-23 11:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-08 14:53 [PATCH v5 0/6] timers: Exclude isolated cpus from timer migation Gabriele Monaco
2025-05-08 14:53 ` [PATCH v5 1/6] timers: Rename tmigr 'online' bit to 'available' Gabriele Monaco
2025-05-08 14:53 ` [PATCH v5 2/6] timers: Add the available mask in timer migration Gabriele Monaco
2025-05-08 14:53 ` [PATCH v5 3/6] cgroup/cpuset: Rename update_unbound_workqueue_cpumask() to update_exclusion_cpumasks() Gabriele Monaco
2025-05-08 14:53 ` [PATCH v5 4/6] sched/isolation: Force housekeeping if isolcpus and nohz_full don't leave any Gabriele Monaco
2025-05-20 10:17   ` Frederic Weisbecker
2025-05-20 11:17     ` Gabriele Monaco
2025-05-20 11:57       ` Frederic Weisbecker
2025-05-20 12:02   ` Frederic Weisbecker
2025-05-20 12:28     ` Gabriele Monaco
2025-05-08 14:53 ` [PATCH v5 5/6] cgroup/cpuset: Fail if isolated and nohz_full don't leave any housekeeping Gabriele Monaco
2025-05-20 13:39   ` Gabriele Monaco
2025-05-20 14:28   ` Frederic Weisbecker
2025-05-20 15:24     ` Gabriele Monaco
2025-05-23 11:15     ` Gabriele Monaco [this message]
2025-06-24 14:11       ` Frederic Weisbecker
2025-05-08 14:53 ` [PATCH v5 6/6] timers: Exclude isolated cpus from timer migation Gabriele Monaco
2025-05-20 14:43   ` Frederic Weisbecker

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=3acad4a1a07ccbde615ea19eb13a96f37d4a3a2f.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).