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.
next prev parent 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.