linux-kernel - Re: [GIT PULL] Introduce housekeeping subsystem v4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 20 Oct 2017 10:17:38 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Frederic Weisbecker <fweisbec@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Chris Metcalf <cmetcalf@...lanox.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Luiz Capitulino <lcapitulino@...hat.com>,
        Christoph Lameter <cl@...ux.com>,
        "Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
        Mike Galbraith <efault@....de>, Rik van Riel <riel@...hat.com>,
        Wanpeng Li <kernellwp@...il.com>
Subject: Re: [GIT PULL] Introduce housekeeping subsystem v4


* Frederic Weisbecker <fweisbec@...il.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