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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170810125437.GA8754@lerouge>
Date:   Thu, 10 Aug 2017 14:54:40 +0200
From:   Frederic Weisbecker <fweisbec@...il.com>
To:     Chris Metcalf <cmetcalf@...lanox.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Luiz Capitulino <lcapitulino@...hat.com>,
        Christoph Lameter <cl@...ux.com>,
        "Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
        Ingo Molnar <mingo@...nel.org>, Mike Galbraith <efault@....de>,
        Rik van Riel <riel@...hat.com>,
        Wanpeng Li <kernellwp@...il.com>
Subject: Re: [RFC PATCH 0/9] Introduce housekeeping subsystem

On Fri, Jul 21, 2017 at 03:48:16PM -0400, Chris Metcalf wrote:
> On 7/21/2017 9:21 AM, Frederic Weisbecker wrote:
> >I'm leaving for two weeks so this is food for thoughts in the meantime :)
> >
> >We have a design issue with nohz_full: it drives the isolation features
> >through the *housekeeping*() functions: kthreads, unpinned timers,
> >watchdog, ...
> >
> >But things should work the other way around because the tick is just an
> >isolation feature among others.
> >
> >So we need a housekeeping subsystem to drive all these isolation
> >features, including nohz full in a later iteration. For now this is a
> >basic draft. In the long run this subsystem should also drive the tick
> >offloading (remove residual 1Hz) and all unbound kthreads.
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> >	nohz/0hz
> >
> >HEAD: 68e3af1de5db228bf6c2a5e721bce59a02cfc4e1
> 
> For the series:
> 
> Reviewed-by: Chris Metcalf <cmetcalf@...lanox.com>
> 
> I spotted a few typos that you should grep for and fix for your next
> version:
> "watchog", "Lets/lets" instead of "Let's/let's", "overriden" (should have
> two d's).

Thanks, I'll check those.

> 
> The new housekeeping=MASK boot option seems like it might make it a little
> irritating to specify nohz_full=MASK as well.  I guess if setting
> NO_HZ_FULL_ALL
> implied "all but housekeeping", it becomes a reasonably tidy solution.  To
> make
> this work right you might have to make the housekeeping option early_param
> instead so its value is available early enough.

Good point. But perhaps I should add a new NO_HZ_FULL_BUT_HOUSEKEEPING option.
Otherwise we'll change the meaning of NO_HZ_FULL_ALL way too much, to the point
that its default behaviour will be the exact opposite of the current one: by default
every CPU is housekeeping, so NO_HZ_FULL_ALL would have no effect anymore if we
don't set housekeeping boot option.

Also I plan to add a housekeeping option to offload the residual 1Hz tick from
nohz_full CPUs. So having "housekeeping=0,tick_offload" would make CPU 0 the
housekeeper, make the other CPUs nohz_full and handle their 1hz tick from CPU 0.

Just a few thoughts.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ