linux-kernel - Re: [PATCH v11 7/9] cpuset: Expose cpus.effective and mems.effective on cgroup v2 root

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: <4cf9924e-7b97-187f-a1f5-853a45165abb@redhat.com>
Date:   Fri, 6 Jul 2018 16:32:25 -0400
From:   Waiman Long <longman@...hat.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     Li Zefan <lizefan@...wei.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>, cgroups@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        kernel-team@...com, pjt@...gle.com, luto@...capital.net,
        Mike Galbraith <efault@....de>, torvalds@...ux-foundation.org,
        Roman Gushchin <guro@...com>,
        Juri Lelli <juri.lelli@...hat.com>,
        Patrick Bellasi <patrick.bellasi@....com>
Subject: Re: [PATCH v11 7/9] cpuset: Expose cpus.effective and mems.effective
 on cgroup v2 root

On 07/03/2018 11:58 AM, Tejun Heo wrote:
> Hello, Waiman.
>
> On Tue, Jul 03, 2018 at 08:41:31AM +0800, Waiman Long wrote:
>>> So, effective changing when enabling partition on a child feels wrong
>>> to me.  It's supposed to contain what's actually allowed to the cgroup
>>> from its parent and that shouldn't change regardless of how those
>>> resources are used.  It's still given to the cgroup from its parent.
>> Another way to work around this issue is to expose the reserved_cpus in
>> the parent for holding CPUs that can taken by a chid partition. That
>> will require adding one more cpuset file for those cgroups that are
>> partition roots.
> Yeah, that should work.
>

Thinking about it a bit more, that approach will make creating a
partition a multi-step process:

1) Reserve the CPUs in reserved_cpus.
2) enable sched.partition
3) Write the CPUs list into cpus.

There are also more exception cases that need to be handled. The current
approach, on the other hands, is much simpler and easier to understand
and use.

>> I don't mind restricting that to the first level children for now. That
>> does restrict where we can put the container root if we want a separate
>> partition for a container. Let's hear if others have any objection about
>> that.
> As currently implemented, partioning locks away the cpus which should
> be a system level decision, not container level, so it makes sense to
> me that it is only available to system root.

So my preference is to allow partition only on the first level children
of the root for the time being. I think it should cover most of the use
cases. I will update the patchset to reflect that.

Cheers,
Longman