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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180719153045.GT72677@devbig577.frc2.facebook.com>
Date:   Thu, 19 Jul 2018 08:30:45 -0700
From:   Tejun Heo <tj@...nel.org>
To:     Waiman Long <longman@...hat.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Li Zefan <lizefan@...wei.com>,
        Johannes Weiner <hannes@...xchg.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

Hello,

On Thu, Jul 19, 2018 at 10:04:54AM -0400, Waiman Long wrote:
> > Why would a container not be allowed to create partitions for its
> > various RT workloads?
> 
> As far as I understand, Tejun has some concern about the way that
> partitioning works is inconsistent with how other resources are being
> managed by cgroup v2 controllers. I adds an incremental patch to
> temporarily disable the creation of partition below the first level
> children to buy us time so that we can reach a compromise later on what
> to do. We can always add features, but taking away features after they
> are made available will be hard.
> 
> I am fine either way. It is up to you and Tejun to figure out what
> should be made available to the users.

So, the main thing is that putting a cpu into a partition locks away
the cpu from its ancestors.  That's a system level operation which
isn't delegatable.  If we want to allow partitioning in subtrees, the
parent still be able to take away partitioned cpus too even if that
means ignoring descendants' configurations, which btw is exactly what
cpuset does for non-partition configs.

I don't think this would be technically too challenging to implement,
but unless there are immediate use cases for it, we can start simpler
& restricted.

Thanks.

-- 
tejun