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 16:29:01 +0200
From:   Frederic Weisbecker <frederic@...nel.org>
To:     Ingo Molnar <mingo@...nel.org>
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

2017-10-20 10:17 UTC+02:00, Ingo Molnar <mingo@...nel.org>:
> 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 see, so indeed that's the kind of thing we want to also confine to
housekeeping as
well whenever possible but these cases require special treatment that need to be
handled by the subsystem in charge. For example vmstat has the vmstat_sheperd
thing which allows to drive those timers adaptively on demand to make sure that
userspace isn't interrupted. The others will likely need some similar treatment.

For now I only see vmstat having such a feature and it acts
transparently. There is
also the LRU flush (IIRC) which needs to be called for example before
returning to
userspace to avoid IPIs. Such things may indeed need special treatment. With the
current patchset it could be a housekeeping flag.

>
> 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'd rather talk about CPU affinity than global time. For example
timers, watchdog, idle load balancing are about periodic events but
workqueues (not the deffered ones), domain isolation (isolcpus), NAPI
polling are perhaps more event driven.

But indeed global timeline based periodic events are not all of what
housekeeping needs to care about.

>
>> > 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?

This is the isolcpus thing which excludes a set of CPUs from the whole
domain tree. That one
doesn't fall into any category we talked about.

In fact, CPU affinity is the only high level concept I found to gather
all these housekeeping
elements.

Perhaps I should use "cpu_isolation" instead of "housekeeping" naming.

Thanks.