All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] sched/isolation: Add HK_FLAG_SCHED to nohz_full
Date: Wed, 4 Sep 2024 14:44:26 +0200	[thread overview]
Message-ID: <ZthWKgK9B_AUqSs1@localhost.localdomain> (raw)
In-Reply-To: <4822d111-b02d-469a-a457-46392c35021f@redhat.com>

Le Tue, Sep 03, 2024 at 09:23:53PM -0400, Waiman Long a écrit :
> > After discussing with Peter lately, the rules should be:
> > 
> > 1) If a nohz_full CPU is part of a multi-CPU domain, then it should
> >     be part of load balancing. Peter even says that nohz_full should be
> >     forbidden in this case, because the tick plays a role in the
> >     load balancing.
> 
> My understand is that most users will use nohz_full together with isolcpus.
> So nohz_full CPUs are also isolated and not in a sched domain. There may
> still be user setting nohz_full without isolcpus though, but that should be
> relatively rare.

Apparently there are users wanting to use isolation along with automatic
containers deployments such as kubernetes, which doesn't seem to work
well with isolcpus...

> 
> Anyway, all these nohz_full/kernel_nose setting will only apply to CPUs in
> isolated cpuset partitions which will not be in a sched domain.
> 
> > 
> > 2) Otherwise, if CPU is not part of a domain or it is the only CPU of all its
> >     domains, then it can be out of the load balancing machinery.
> I am aware that a single-cpu domain is the same as being isolated with no
> load balancing.

By the way is it possible to have a single-cpu domain (sorry I'm a noob here)
or do such CPU always end up on a null domain?

If it is possible, it's interesting to notice that such CPU can become ilb
(as opposed to null domain).

> > 
> > I'm a bit scared about rule 1) because I know there are existing users of
> > nohz_full on multi-CPU domains... So I feel a bit trapped.
> 
> As stated before, this is not a common use case.

Not sure and anyway it's not a forbidden usecase. But this is anyway outside
the scope of this patchset.

> The isolcpus boot option is deprecated, as stated in kernel-parameters.txt.

We should undeprecate it, apparently it's still widely used. Perhaps by people
who can't afford to use cpusets/cgroups.

> My plan is to deprecate nohz_full as well once we are able to make dynamic
> CPU isolation via cpuset works almost as good as isolcpus + nohz_full.

You can't really deprecate such a kernel boot option unfortunately. Believe me
I wish we could.

Thanks.

> Cheers,
> Longman
> 

  reply	other threads:[~2024-09-04 12:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-18 23:45 [PATCH 0/3] sched: Miscellaneous isolation related cleanups Waiman Long
2024-08-18 23:45 ` [PATCH 1/3] sched/isolation: Add HK_FLAG_SCHED to nohz_full Waiman Long
2024-09-03 13:10   ` Frederic Weisbecker
2024-09-03 13:24     ` Waiman Long
2024-09-03 21:32       ` Frederic Weisbecker
2024-09-04  1:23         ` Waiman Long
2024-09-04 12:44           ` Frederic Weisbecker [this message]
2024-09-04 13:04             ` Peter Zijlstra
2024-09-04 13:41               ` Waiman Long
2024-09-04 13:44               ` Phil Auld
2024-09-04 14:02                 ` Peter Zijlstra
2024-09-04 14:32                   ` Phil Auld
2024-09-04 14:09                 ` Waiman Long
2024-09-06 12:36               ` Frederic Weisbecker
2024-08-18 23:45 ` [PATCH 2/3] sched/fair: Use HK_TYPE_SCHED housekeeping CPUs Waiman Long
2024-09-03 13:12   ` Frederic Weisbecker
2024-09-03 13:53     ` Waiman Long
2024-09-04 14:54       ` Waiman Long
2024-09-06 12:53         ` Frederic Weisbecker
2024-09-06 16:31           ` Waiman Long
2024-08-18 23:45 ` [PATCH 3/3] sched/isolation: Consolidate housekeeping cpumasks that are always identical Waiman Long
2024-08-23 18:23 ` [PATCH 0/3] sched: Miscellaneous isolation related cleanups Waiman Long

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=ZthWKgK9B_AUqSs1@localhost.localdomain \
    --to=frederic@kernel.org \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --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 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.