linux-kernel - Re: [RFC PATCH-cgroup 1/6] cgroup: Relax the no internal process constraint

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:   Wed, 21 Jun 2017 18:02:03 -0400
From:   Tejun Heo <tj@...nel.org>
To:     Waiman Long <longman@...hat.com>
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, kernel-team@...com, pjt@...gle.com,
        luto@...capital.net, efault@....de, torvalds@...ux-foundation.org
Subject: Re: [RFC PATCH-cgroup 1/6] cgroup: Relax the no internal process
 constraint

Hey,

On Wed, Jun 21, 2017 at 05:50:09PM -0400, Waiman Long wrote:
> >> I think CPU isn't a good example for that.
> > Can you please elaborate?
> 
> CPU is probably the most prominent controller where deep hierarchy has a
> performance cost. So I can't envision that it will forbid internal
> process competition.

I think there's a fundamental misunderstanding here.  The internal
competion thing is about how to account for resource consumptions
which aren't tied to specific processes or tasks.  Thread mode allows
building sub-hierarchy beyond the domain point while still keeping the
domain at the root of the thread subtree.  It is true that as
currently implemented, CPU controller has performance issues for some
workloads even with a moderate level of nesting (and quite a bit of
other artifacts from nesting too); however, supporting control of
anonymous resources or not is an orthogonal issue.  People can enable
thread mode at the root if that's applicable to the workload at hand
but you can't change what the basic topology means because a
controller has performance overhead.

> >> Another alternative is to treat no internal process as a controller
> >> attribute. Then we don't need to worry about this intricate question and
> >> let the  controllers decide if they will allow internal processes.
> > Isn't that what "threaded" is?
> 
> That is exactly what this patch intends to do. However, you raised
> concern that threaded may not be equivalent to the need of allowing
> internal process. That is why I propose that. If your concern is only
> about the documentation change, we can certainly fix that.

I'm really lost on what this actually achieves.  Can we please first
talk about what you're trying to enable?  Let's talk about features
and capabilities first because it feels like most of the changes in
this patchset lack them and we seem to be talking past each other.

Thanks.

-- 
tejun