From: Ingo Molnar <mingo@kernel.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Chris Metcalf <cmetcalf@mellanox.com>,
Thomas Gleixner <tglx@linutronix.de>,
Luiz Capitulino <lcapitulino@redhat.com>,
Christoph Lameter <cl@linux.com>,
"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
Mike Galbraith <efault@gmx.de>, Rik van Riel <riel@redhat.com>,
Wanpeng Li <kernellwp@gmail.com>
Subject: Re: [GIT PULL] Introduce housekeeping subsystem v4
Date: Fri, 20 Oct 2017 10:17:38 +0200 [thread overview]
Message-ID: <20171020081738.cb6ycok7a3bmtafr@gmail.com> (raw)
In-Reply-To: <1614fd90-f334-ed4b-3698-e799f29e4e35@gmail.com>
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> Indeed I feel that housekeeping is probably not the best concept to express
> all these things. I'm all for something clearer.
>
> >
> > So how about introducing _two_ new high level concepts:
> >
> > 1) 'global time handling'
> > 2) 'double async CPU callbacks'
> >
> > The notion of 'global time' handling is obvious to everyone I think: it involves
> > the system-global guarantee that certain kernel jobs will be executed
> > periodically. At least one CPU in the system needs to handle 'global time'.
> >
> > The notion of 'double async CPU callbacks' is less obvious: it involves the action
> > of invoking a callback on a CPU, that might be executed on _another_ CPU.
> >
> > I.e. there are 3 CPUs involved:
> >
> > - the invoking CPU
> > - the target CPU
> > - the CPU(s!) that will handle the callback (the housekeeping CPU mask)
> >
> > For example the kmem-cache on_each_cpu() calls in mm/slab.c would fall into this
> > category.
>
> Hmm, I'm not clear on this one. Do you mean works that can be executed
> concurrently?
I mean code like:
triton:~/tip> git grep on_each_cpu mm
mm/page_alloc.c: * cpu to drain that CPU pcps and on_each_cpu_mask
mm/slab.c: on_each_cpu(do_drain, cachep, 1);
mm/slub.c: on_each_cpu_cond(has_cpu_slab, flush_cpu_slab, s, 1, GFP_ATOMIC);
mm/vmstat.c: err = schedule_on_each_cpu(refresh_vm_stats);
is something we want to execute on 'housekeeping CPUs' as well, to not disturb the
isolated CPUs, right?
I.e. right now most (or all) of your patchset could be done using the
'global_time_*()' (or so) naming - I just wanted to mention that work related to
global timeline is not the only jobs that housekeeping CPUs will have to
eventually execute.
> > I don't know to what extent it makes sense to formalize and unify these
> > facilities: it's certain that the (former) housekeeping CPU mask should be shared
> > by these two facilities: the CPU executing global time callbacks periodically
> > should be one of the CPUs that execute double-async CPU callbacks.
> >
> > But by separating all this functionality into these two categories, it's already
> > much easier to me to argue about which bit does what and why.
>
> Note that some housekeeping concepts may not fall into any of these
> categories. For example domain isolation.
Could you describe domain isolation?
Thanks,
Ingo
next prev parent reply other threads:[~2017-10-20 8:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-18 13:53 Frederic Weisbecker
2017-09-18 13:53 ` [PATCH 01/12] housekeeping: Move housekeeping related code to its own file Frederic Weisbecker
2017-09-18 13:53 ` [PATCH 02/12] watchdog: Use housekeeping_cpumask() instead of ad-hoc version Frederic Weisbecker
2017-09-18 13:54 ` [PATCH 03/12] housekeeping: Provide a dynamic off-case to housekeeping_any_cpu() Frederic Weisbecker
2017-09-18 13:54 ` [PATCH 04/12] housekeeping: Make housekeeping cpumask private Frederic Weisbecker
2017-09-18 13:54 ` [PATCH 05/12] housekeeping: Use its own static key Frederic Weisbecker
2017-09-18 13:54 ` [PATCH 06/12] housekeeping: Rename is_housekeeping_cpu to housekeeping_cpu Frederic Weisbecker
2017-09-18 13:54 ` [PATCH 07/12] housekeeping: Move it under its own config, independant from NO_HZ Frederic Weisbecker
2017-09-18 13:54 ` [PATCH 08/12] housekeeping: Introduce housekeeping flags Frederic Weisbecker
2017-09-18 13:54 ` [PATCH 09/12] housekeeping: Handle nohz_full= parameter Frederic Weisbecker
2017-09-18 13:54 ` [PATCH 10/12] housekeeping: Move isolcpus to housekeeping Frederic Weisbecker
2017-09-18 13:54 ` [PATCH 11/12] housekeeping: Add basic isolcpus flags Frederic Weisbecker
2017-09-18 13:54 ` [PATCH 12/12] housekeeping: Document " Frederic Weisbecker
2017-09-28 9:54 ` [GIT PULL] Introduce housekeeping subsystem v4 Ingo Molnar
2017-09-29 13:34 ` Frederic Weisbecker
2017-10-01 6:36 ` Christopher Lameter
2017-10-15 15:53 ` Frederic Weisbecker
2017-10-20 8:17 ` Ingo Molnar [this message]
2017-10-20 14:29 ` Frederic Weisbecker
2017-10-21 16:07 ` Chris Metcalf
2017-10-23 12:06 ` Ingo Molnar
2017-10-24 2:42 ` 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=20171020081738.cb6ycok7a3bmtafr@gmail.com \
--to=mingo@kernel.org \
--cc=cl@linux.com \
--cc=cmetcalf@mellanox.com \
--cc=efault@gmx.de \
--cc=fweisbec@gmail.com \
--cc=kernellwp@gmail.com \
--cc=lcapitulino@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=riel@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
Powered by JetHome