linux-kernel - RE: [PATCH v8 0/6] cgroup/cpuset: Add new cpuset partition type & empty effecitve cpus

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]

Message-ID: <AM9PR10MB4869C14EAE01B87C0037BF6A89939@AM9PR10MB4869.EURPRD10.PROD.OUTLOOK.COM>
Date:   Wed, 10 Nov 2021 15:21:54 +0000
From:   "Moessbauer, Felix" <felix.moessbauer@...mens.com>
To:     Michal Koutný <mkoutny@...e.com>
CC:     "longman@...hat.com" <longman@...hat.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
        "corbet@....net" <corbet@....net>,
        "frederic@...nel.org" <frederic@...nel.org>,
        "guro@...com" <guro@...com>,
        "hannes@...xchg.org" <hannes@...xchg.org>,
        "juri.lelli@...hat.com" <juri.lelli@...hat.com>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "lizefan.x@...edance.com" <lizefan.x@...edance.com>,
        "mtosatti@...hat.com" <mtosatti@...hat.com>,
        "pauld@...hat.com" <pauld@...hat.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "tj@...nel.org" <tj@...nel.org>,
        "jan.kiszka@...mens.com" <jan.kiszka@...mens.com>,
        "henning.schild@...mens.com" <henning.schild@...mens.com>
Subject: RE: [PATCH v8 0/6] cgroup/cpuset: Add new cpuset partition type &
 empty effecitve cpus



> -----Original Message-----
> From: Michal Koutný <mkoutny@...e.com>
> Sent: Wednesday, November 10, 2021 2:57 PM
> To: Moessbauer, Felix (T RDA IOT SES-DE) <felix.moessbauer@...mens.com>
> Cc: longman@...hat.com; akpm@...ux-foundation.org;
> cgroups@...r.kernel.org; corbet@....net; frederic@...nel.org; guro@...com;
> hannes@...xchg.org; juri.lelli@...hat.com; linux-doc@...r.kernel.org; linux-
> kernel@...r.kernel.org; linux-kselftest@...r.kernel.org;
> lizefan.x@...edance.com; mtosatti@...hat.com; pauld@...hat.com;
> peterz@...radead.org; shuah@...nel.org; tj@...nel.org; Kiszka, Jan (T RDA
> IOT) <jan.kiszka@...mens.com>; Schild, Henning (T RDA IOT SES-DE)
> <henning.schild@...mens.com>
> Subject: Re: [PATCH v8 0/6] cgroup/cpuset: Add new cpuset partition type &
> empty effecitve cpus
> 
> Hello.
> 
> On Wed, Nov 10, 2021 at 12:13:57PM +0100, Felix Moessbauer
> <felix.moessbauer@...mens.com> wrote:
> > However, I was not able to see any latency improvements when using
> > cpuset.cpus.partition=isolated.
> 
> Interesting. What was the baseline against which you compared it (isolcpus, no
> cpusets,...)?

For this test, I just compared both settings cpuset.cpus.partition=isolated|root.
There, I did not see a significant difference (but I know, RT tuning depends on a ton of things).

> 
> > The test was performed with jitterdebugger on CPUs 1-3 and the following
> cmdline:
> > rcu_nocbs=1-4 nohz_full=1-4 irqaffinity=0,5-6,11 intel_pstate=disable
> > On the other cpus, stress-ng was executed to generate load.
> > [...]
> 
> > This requires cgroup.type=threaded on both cgroups and changes to the
> > application (threads have to be born in non-rt group and moved to rt-group).
> 
> But even with isolcpus the application would need to set affinity of threads to
> the selected CPUs (cf cgroup migrating). Do I miss anything?

Yes, that's true. But there are two differences (given that you use isolcpus):
1. the application only has to set the affinity for rt threads.
 Threads that do not explicitly set the affinity are automatically excluded from the isolated cores.
 Even common rt test applications like jitterdebugger do not pin their non-rt threads.
2. Threads can be started on non-rt CPUs and then bound to a specific rt CPU.
This binding can be specified before thread creation via pthread_create.
By that, you can make sure that at no point in time a thread has a "forbidden" CPU in its affinities.

With cgroup2, you cannot guarantee the second aspect, as thread creation and moving to a cgroup is not an atomic operation.
Also - please correct me if I'm wrong - you first have to create a thread before moving it into a group.
At creation time, you cannot set the final affinity mask (as you create it in the non-rt group and there the CPU is not in the cpuset.cpus).
Once you move the thread to the rt cgroup, it has a default mask and by that can be executed on other rt cores.

Best regards,
Felix

> 
> Thanks,
> Michal