linux-kernel - Re: [patch 2/3] isolcpus: affine kernel threads to specified cpumask

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:   Tue, 31 Mar 2020 08:50:14 -0300
From:   Marcelo Tosatti <mtosatti@...hat.com>
To:     Frederic Weisbecker <frederic@...nel.org>
Cc:     linux-kernel@...r.kernel.org,
        Frederic Weisbecker <fweisbec@...il.com>,
        Chris Friesen <chris.friesen@...driver.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jim Somerville <Jim.Somerville@...driver.com>,
        Christoph Lameter <cl@...ux.com>
Subject: Re: [patch 2/3] isolcpus: affine kernel threads to specified cpumask

On Tue, Mar 31, 2020 at 02:57:08AM +0200, Frederic Weisbecker wrote:
> On Sat, Mar 28, 2020 at 12:21:19PM -0300, Marcelo Tosatti wrote:
> > This is a kernel enhancement to configure the cpu affinity of kernel threads via kernel boot option isolcpus=no_kthreads,<isolcpus_params>,<cpulist>
> > 
> > When this option is specified, the cpumask is immediately applied upon
> > thread launch. This does not affect kernel threads that specify cpu
> > and node.
> > 
> > This allows CPU isolation (that is not allowing certain threads
> > to execute on certain CPUs) without using the isolcpus=domain parameter,
> > making it possible to enable load balancing on such CPUs
> > during runtime (see kernel-parameters.txt).
> > 
> > Note-1: this is based off on Wind River's patch at
> > https://github.com/starlingx-staging/stx-integ/blob/master/kernel/kernel-std/centos/patches/affine-compute-kernel-threads.patch
> > 
> > Difference being that this patch is limited to modifying
> > kernel thread cpumask: Behaviour of other threads can
> > be controlled via cgroups or sched_setaffinity.
> > 
> > Note-2: Wind River's patch was based off Christoph Lameter's patch at
> > https://lwn.net/Articles/565932/ with the only difference being
> > the kernel parameter changed from kthread to kthread_cpus.
> > 
> > Signed-off-by: Marcelo Tosatti <mtosatti@...hat.com>
> > 
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt |    8 ++++++++
> >  include/linux/sched/isolation.h                 |    1 +
> >  kernel/kthread.c                                |    6 ++++--
> >  kernel/sched/isolation.c                        |    6 ++++++
> >  4 files changed, 19 insertions(+), 2 deletions(-)
> > 
> > Index: linux-2.6/Documentation/admin-guide/kernel-parameters.txt
> > ===================================================================
> > --- linux-2.6.orig/Documentation/admin-guide/kernel-parameters.txt
> > +++ linux-2.6/Documentation/admin-guide/kernel-parameters.txt
> > @@ -1959,6 +1959,14 @@
> >  			  the CPU affinity syscalls or cpuset.
> >  			  <cpu number> begins at 0 and the maximum value is
> >  			  "number of CPUs in system - 1".
> > +			  When using cpusets, use the isolcpus option "kthread"
> > +			  to avoid creation of kernel threads on isolated CPUs.
> > +
> > +			kthread
> > +			  Adjust the CPU affinity mask of unbound kernel threads to
> > +			  not contain CPUs on the isolated list. This complements
> > +			  the isolation provided by the cpusets mechanism described
> > +			  above and by managed_irq option.

Hi Frederic,

> So, what about what I suggested with having "unbound" instead, which
> includes all the CPU-unbound work?
> 
>  HK_FLAG_WQ | HK_FLAG_TIMER | HK_FLAG_RCU | HK_FLAG_MISC | HK_FLAG_KTHREAD | HK_FLAG_SCHED

After more thought, it would share certain flags with nohz_full=, which
seemed confusing.

> (and yes your suggestion of including HK_FLAG_SCHED is good).
> 
> Because I don't see the point of exposing kthread isolation alone as an ABI
> so far.
> 
> Later I suspect I'll turn all these flags into a single HK_FLAG_UNBOUND.

How about keeping the flags separate, and then on top of that do
an "unbound" flag (less typing needed).

This would allow users to combine the individual flags (again, useful
for debugging) while at the same time having an option which groups
all the others?