From: Frederic Weisbecker <frederic@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
mingo@kernel.org, linux-kernel@vger.kernel.org,
valentin.schneider@arm.com, morten.rasmussen@foss.arm.com,
brendan.jackman@arm.com, dietmar.eggemann@arm.com,
Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH v3 3/3] sched: update blocked load when newly idle
Date: Thu, 1 Mar 2018 17:09:20 +0100 [thread overview]
Message-ID: <20180301160918.GC29639@lerouge> (raw)
In-Reply-To: <20180212153805.GW25201@hirez.programming.kicks-ass.net>
On Mon, Feb 12, 2018 at 04:38:05PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 12, 2018 at 03:34:44PM +0100, Vincent Guittot wrote:
> > > Aside from the above being an unreadable mess, I dislike that it breaks
> > > the various isolation crud, we should not touch CPUs outside of our
> > > domain.
> > >
> > >
> > > Maybe something like the below? (unfinished)
> > >
> >
> > good catch. I completely miss the isolation stuff.
> > But isn't already the case when kicking ilb ? I mean that an idle CPU touches
> > all idle CPUs and some can be outside its domain during ilb.
>
> > Shouldn't we test housekeeping_cpu(cpu, HK_FLAG_SCHED) instead if we want to
> > make sure that an isolated/full nohz CPU will not be used for updating blocked
> > load of CPUs outside its domain ?
>
> I _thought_ we had some 'housekeeping' crud in the ilb selection logic,
> but now I can't find it. Frederic?
I think you're referring to nohz_balance_idle(). The call is still there but HK_FLAG_SCHED
is unused for now. I initially turned it on by default on nohz_full but some people
complained. I don't recall why exactly. Anyway I'm waiting for a suitable interface
to use it.
prev parent reply other threads:[~2018-03-01 16:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-12 8:07 [PATCH v3 0/3] sched: Update blocked load Vincent Guittot
2018-02-12 8:07 ` [PATCH v3 1/3] sched: Stop nohz stats when decayed Vincent Guittot
2018-02-12 9:41 ` Peter Zijlstra
2018-02-12 9:52 ` Vincent Guittot
2018-02-12 10:45 ` Peter Zijlstra
2018-02-12 11:02 ` Vincent Guittot
2018-02-12 8:07 ` [PATCH v3 2/3] sched: reduce the periodic update duration Vincent Guittot
2018-02-12 8:07 ` [PATCH v3 3/3] sched: update blocked load when newly idle Vincent Guittot
2018-02-12 12:04 ` Peter Zijlstra
2018-02-12 14:34 ` Vincent Guittot
2018-02-12 15:38 ` Peter Zijlstra
2018-02-12 16:06 ` Vincent Guittot
2018-03-01 16:09 ` Frederic Weisbecker [this message]
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=20180301160918.GC29639@lerouge \
--to=frederic@kernel.org \
--cc=brendan.jackman@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=morten.rasmussen@foss.arm.com \
--cc=peterz@infradead.org \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
/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.