lkml.org 
[lkml]   [2017]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCHSET for-4.11] cgroup: implement cgroup v2 thread mode
    On Thu, Feb 2, 2017 at 1:52 PM, Tejun Heo <tj@kernel.org> wrote:
    > Hello,
    >
    > On Thu, Feb 02, 2017 at 01:32:19PM -0800, Andy Lutomirski wrote:
    >> > * Thread mode is explicitly enabled on a cgroup by writing "enable"
    >> > into "cgroup.threads" file. The cgroup shouldn't have any child
    >> > cgroups or enabled controllers.
    >>
    >> Why do you need to manually turn it on? That is, couldn't it be
    >> automatic based on what controllers are enabled?
    >
    > This came up already but it's not like some controllers are inherently
    > thread-only. Consider CPU, all in-context CPU cycle consumptions are
    > tied to the thread; however, we also want to be able to account for
    > CPU cycles consumed for, for example, memory reclaim or encryption
    > during writeback.
    >

    Is this flexible enough for the real-world usecases? For my use case
    (if I actually ported over to this), it would mean that I'd have to
    enable thread mode on the root. What about letting a given process
    (actually mm, perhaps) live in a cgroup but let the threads be in
    different cgroups without any particular constraints. Then
    process-wide stuff would be accounted to the cgroup that owns the
    process.

    >
    >> > * Once enabled, arbitrary sub-hierarchy can be created and threads can
    >> > be put anywhere in the subtree by writing TIDs into "cgroup.threads"
    >> > file. Process granularity and no-internal-process constraint don't
    >> > apply in a threaded subtree.
    >>
    >> I'm a bit worried that this conflates two different things. There's
    >> thread support, i.e. allowing individual threads to be placed into
    >> cgroups. There's also more flexible sub-hierarchy support, i.e.
    >> relaxing no-internal-process constraints. For the "cpuacct"
    >> controller, for example, both of these make sense. But what if
    >> someone writes a controller (directio, for example, just to make
    >> something up) for which thread granularity makes sense but relaxing
    >> no-internal-process constraints does not?
    >
    > If a controller can't possibly define how internal competition should
    > be handled, which is unlikely - the problem is being consistent and
    > sensible, defining something isn't difficult - the controller can
    > simply error out those cases either on configuration or migration.
    > Again, I'm very doubtful we'll need that but if we ever need that
    > denying specific configurations is the best we can do anyway.
    >

    I'm not sure I follow.

    I'm suggesting something quite simple: let controllers that don't need
    the no-internal-process constraints set a flag so that the constraints
    don't apply if all enabled controllers have the flag set.

    --Andy

    \
     
     \ /
      Last update: 2017-02-03 22:11    [W:8.645 / U:0.508 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site