linux-kernel - Re: [RFC PATCH] time/nohz: allow the boot CPU to be nohz

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:   Wed, 23 Jan 2019 18:25:26 +1000
From:   Nicholas Piggin <npiggin@...il.com>
To:     Frederic Weisbecker <frederic@...nel.org>
Cc:     Frederic Weisbecker <fweisbec@...il.com>,
        linux-kernel@...r.kernel.org, Michael Neuling <mikey@...ling.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH] time/nohz: allow the boot CPU to be nohz_full

Frederic Weisbecker's on January 17, 2019 3:54 am:
> On Mon, Jan 14, 2019 at 04:47:45PM +1000, Nicholas Piggin wrote:
>> We have a supercomputer site testing nohz_full to reduce jitter with
>> good results, but they want CPU0 to be nohz_full. That happens to be
>> the boot CPU, which is disallowed by the nohz_full code.
>> 
>> They have existing job scheduling code which wants this, I don't know
>> too much detail beyond that, but I hope the kernel can be made to
>> work with their config.
>> 
>> This patch has the boot CPU take over the jiffies update in the low
>> res timer before SMP is brought up, after which the nohz CPU will take
>> over.
>> 
>> It also modifies the housekeeping check code a bit to ensure at least
>> one !nohz CPU is in the present map so it comes up at boot, rather
>> than having the nohz code take the boot CPU out of the nohz mask.
>> 
>> This keeps jiffies incrementing on the nohz_full boot CPU before SMP
>> init, but I'm not sure if this is covering all races and platform
>> considerations. Sorry I don't know the timer code too well, I would
>> appreciate any help.
>> 
>> Thanks,
>> Nick
> 
> We used to allow that and that broke hibernation :)

Oh interesting to know thanks, I'll look up the old code.

> So, since we need to have at least one CPU alive to handle the
> timekeeping updates on behalf of nohz CPUs, we forbid it to go idle
> and offline, for simplicity. Now hibernation requires to disable
> non-boot CPUs. So if the timekeeper is not the boot CPU, it's going to
> refuse the hotplug operation and break hibernation.

Simplest would be just to make them mutually exclusive. I don't think 
this customer needs hibernation.

In the longer run, I wonder if it would be nice to allow CPUs to change 
in and out of nohz-full mode at runtime, and the time keeper CPU to be 
able to be migrated at runtime like it does for nohz idle. Maybe that's 
over engineering things if there is no real demand for it though.

Thanks,
Nick