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: Tue, 3 Sep 2024 23:32:45 +0200	[thread overview]
Message-ID: <ZteAfUXZd1TgIwiL@pavilion.home> (raw)
In-Reply-To: <7fa3dbd5-7c2e-4614-a5f4-258546cb090b@redhat.com>

Le Tue, Sep 03, 2024 at 09:24:08AM -0400, Waiman Long a écrit :
> 
> On 9/3/24 09:10, Frederic Weisbecker wrote:
> > Le Sun, Aug 18, 2024 at 07:45:18PM -0400, Waiman Long a écrit :
> > > The HK_FLAG_SCHED/HK_TYPE_SCHED flag is defined and is also used
> > > in kernel/sched/fair.c since commit de201559df87 ("sched/isolation:
> > > Introduce housekeeping flags"). However, the corresponding cpumask isn't
> > > currently updated anywhere. So the mask is always cpu_possible_mask.
> > > 
> > > Add it in nohz_full setup so that nohz_full CPUs will now be removed
> > > from HK_TYPE_SCHED cpumask.
> > > 
> > > Signed-off-by: Waiman Long <longman@redhat.com>
> > > ---
> > >   kernel/sched/isolation.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/kernel/sched/isolation.c b/kernel/sched/isolation.c
> > > index 5891e715f00d..a514994af319 100644
> > > --- a/kernel/sched/isolation.c
> > > +++ b/kernel/sched/isolation.c
> > > @@ -196,7 +196,7 @@ static int __init housekeeping_nohz_full_setup(char *str)
> > >   	unsigned long flags;
> > >   	flags = HK_FLAG_TICK | HK_FLAG_WQ | HK_FLAG_TIMER | HK_FLAG_RCU |
> > > -		HK_FLAG_MISC | HK_FLAG_KTHREAD;
> > > +		HK_FLAG_MISC | HK_FLAG_KTHREAD | HK_FLAG_SCHED;
> > >   	return housekeeping_setup(str, flags);
> > >   }
> > find_new_ilb() already has HK_FLAG_MISC to prevent an isolated CPU
> > from being elected as an ilb. So I think we should simply remove HK_FLAG_SCHED.
> 
> There is a check for HK_TYPE_SCHED in nohz_balance_enter_idle() and
> nohz_newidle_balance(), though it is essentially a no-op as the cpumask has
> all the CPUs. If we remove HK_TYPE_SCHED, the question now will be whether
> we should remove the checks at these 2 functions or change them to
> HK_TYPE_MISC.

Just remove those two. They are dead code and the nohz_full handling
of load balancing needs a rethink anyway.

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.

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'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.

Thanks.

  reply	other threads:[~2024-09-03 21:32 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 [this message]
2024-09-04  1:23         ` Waiman Long
2024-09-04 12:44           ` Frederic Weisbecker
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=ZteAfUXZd1TgIwiL@pavilion.home \
    --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.