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] [day] [month] [year] [list]
Message-ID: <521b7c3d-6c30-4176-bd72-d5826eff70cb@redhat.com>
Date:   Tue, 28 Nov 2023 13:19:11 -0500
From:   Waiman Long <longman@...hat.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     Zefan Li <lizefan.x@...edance.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Jonathan Corbet <corbet@....net>,
        Shuah Khan <shuah@...nel.org>, cgroups@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH] cgroup/cpuset: Expose cpuset.cpus.isolated


On 11/28/23 11:46, Tejun Heo wrote:
> Hello,
>
> On Mon, Nov 27, 2023 at 02:51:05PM -0500, Waiman Long wrote:
>> The root-only cpuset.cpus.isolated control file shows the current set
>> of isolated CPUs in isolated partitions. This control file is currently
>> exposed only with the cgroup_debug boot command line option which also
>> adds the ".__DEBUG__." prefix. This is actually a useful control file if
>> users want to find out which CPUs are currently in an isolated state by
>> the cpuset controller. Remove CFTYPE_DEBUG flag for this control file and
>> make it available by default without any prefix.
>>
>> The test_cpuset_prs.sh test script and the cgroup-v2.rst documentation
>> file are also updated accordingly. Minor code change is also made in
>> test_cpuset_prs.sh to avoid false test failure when running on debug
>> kernel.
> Applied to cgroup/for-6.8 but I wonder whether this would be useful in
> non-root cgroups too. e.g. In a delegated partition which is namespaced,
> wouldn't this be useful too?
>
> Thanks.

For simplicity,we only maintain one cpumask of isolated CPUs that 
includes all the exclusive CPUs in isolated partitions. We haven't 
maintain separate masks for delegation purposes. We can certainly extend 
that if the needs arise. At this point, the set of isolated CPUs is 
mainly used for determining what kernel background services can be 
disabled to reduce interference from the whole kernel point of view.

Cheers,
Longman

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ