[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15566148#comment-15566148 ] haosdent commented on MESOS-4697: - Move remain tickets to the improvement epic MESOS-6364 > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a > different hierarchy. This gradually become not true with unified cgroup > hierarchy introduced in kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. But we don't plan to support > cgroup v2 in this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491937#comment-15491937 ] Charles Allen commented on MESOS-4697: -- Cool thanks! > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a > different hierarchy. This gradually become not true with unified cgroup > hierarchy introduced in kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. But we don't plan to support > cgroup v2 in this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491796#comment-15491796 ] Jie Yu commented on MESOS-4697: --- Also, we need to add a blkio subsystem, which should be pretty simple. > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a > different hierarchy. This gradually become not true with unified cgroup > hierarchy introduced in kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. But we don't plan to support > cgroup v2 in this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491797#comment-15491797 ] Jie Yu commented on MESOS-4697: --- Also, we need to add a blkio subsystem, which should be pretty simple. > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a > different hierarchy. This gradually become not true with unified cgroup > hierarchy introduced in kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. But we don't plan to support > cgroup v2 in this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491756#comment-15491756 ] Jie Yu commented on MESOS-4697: --- [~drcrallen] you probably want to start from here: https://github.com/apache/mesos/blob/master/src/slave/containerizer/mesos/isolators/cgroups/cgroups.cpp#L365-L369 , where we create cgroups. > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a > different hierarchy. This gradually become not true with unified cgroup > hierarchy introduced in kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. But we don't plan to support > cgroup v2 in this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491529#comment-15491529 ] Charles Allen commented on MESOS-4697: -- Thanks [~jieyu]! As per my prior comment, I'm very interested in getting per-role cgroup hierarchies so I can tune cgroup settings better, I was under the impression that should be able to be accomplished much easier with the consolidated isolator. If I were to try and find a way to do such a thing, where would be a good starting point? > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a > different hierarchy. This gradually become not true with unified cgroup > hierarchy introduced in kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. But we don't plan to support > cgroup v2 in this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491408#comment-15491408 ] Jie Yu commented on MESOS-4697: --- It all happens magically under the hood. If you use cgroups/cpu,cgroups/mem, it'll use the new isolator automatically, even if in cgroup v2 where all control files are mounted together. > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a > different hierarchy. This gradually become not true with unified cgroup > hierarchy introduced in kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. But we don't plan to support > cgroup v2 in this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15491402#comment-15491402 ] Charles Allen commented on MESOS-4697: -- Now that this is mostly in, are there any particular areas to look (or examples) on how to tinker with the new isolator stuff? > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a > different hierarchy. This gradually become not true with unified cgroup > hierarchy introduced in kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. But we don't plan to support > cgroup v2 in this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295596#comment-15295596 ] Charles Allen commented on MESOS-4697: -- Thank you [~haosd...@gmail.com], that sounds great! > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a > different hierarchy. This gradually become not true with unified cgroup > hierarchy introduced in kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. But we don't plan to support > cgroup v2 in this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[
https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15295040#comment-15295040
]
haosdent commented on MESOS-4697:
-
Hi, [~drcrallen] Thank you very much for your nice feedbacks.
{quote}
I do NOT want to have to go back and update older frameworks to make sure they
play nice with more-modern frameworks with better resource awareness.
{quote}
Certainly we should not break anything for exists frameworks. This is confirmed
in our proposal. Framework developers also should not need to care about the
details about how Mesos isolate resources. All the frameworks need to do is to
implement the interfaces and call the APIs, then Mesos would choose the correct
way to satisfy or decline the requests.
{quote}
What I would love to see is a way for me to have different cgroup roots per
role.
{quote}
This make sense. Currently we create cgroup for every Mesos containers. Because
cgroup v1 allow user to create root hierarchies in different places, it is
tricky to implement it in current architecture(separate isolators for every
cgroup subsystem). It would become doable after we finish unified cgroup
isolator and support cgroup v2. And you may take a look at [QoS Isolator
Proposal |
https://docs.google.com/document/d/1peagt7dNgU78hQbjOz1fwPTs-ftYFP9DXAyetCM7XcY/edit#heading=h.sg28ikrbhimr]
as well. It could set different priorities for your frameworks instead of you
change cgroup configuration in every Mesos Agent.
{quote}
the intended behavior is clarified for when a cgroup is present on a system,
but the version of mesos running is not aware of how to use such a cgroup
{quote}
In this case, Mesos could not isolate resources with those unsupported cgroup
subsystems until upgrade it.
> Consolidate cgroup isolators into one single isolator.
> --
>
> Key: MESOS-4697
> URL: https://issues.apache.org/jira/browse/MESOS-4697
> Project: Mesos
> Issue Type: Epic
>Reporter: Jie Yu
>Assignee: haosdent
> Attachments: cgroup_v2.pdf
>
>
> There are two motivations for this:
> 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu,
> mem, net_cls, etc.), many of the logics are the same. We are currently
> duplicating a lot of the code.
> 2) Initially, we decided to use a separate isolator for each cgroup subsystem
> is because we want each subsystem to be mounted under a
> different hierarchy. This gradually become not true with unified cgroup
> hierarchy introduced in kernel 3.16([The unified control group hierarchy in
> 3.16|https://lwn.net/Articles/601840/],
> [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]).
> Also, on some popular linux distributions, some subsystems are co-mounted
> within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It
> becomes very hard to co-manage a hierarchy by two isolators.
> We can still introduce subsystem specific code under the unified cgroup
> isolator by introduce a Subsystem abstraction. But we don't plan to support
> cgroup v2 in this ticket.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15293970#comment-15293970 ] Charles Allen commented on MESOS-4697: -- General feedback from someone who has written frameworks and deployed other frameworks. Whenever I'm deploying a framework on Mesos, I rarely care about what isolation group it is using. Usually I simply want to have an understanding of how my resources are going to be requested/handled. This comes in play largely with frameworks who have different levels of resource awareness. Some know about memory and cpu, and a select few about disk needs. As the capabilities of resource isolation expand, I do NOT want to have to go back and update older frameworks to make sure they play nice with more-modern frameworks with better resource awareness. My current approach to handling this is through [roles | http://mesos.apache.org/documentation/latest/roles/] where a role is really a pre-agreed upon set of resource expectations. What I would love to see is a way for me to have different cgroup roots per role. Or at least more clear expectations on how to have such a scenario. This way I can tune cgroups at a system level regardless of how aware mesos is of the node's capabilities. As a discrete example, I would like to have blkio tuned on a node such that all tasks from a particular mesos role have some expectations of blkio, all tasks from a DIFFERENT mesos task have some other expectations, and a THIRD group of tasks which are NOT part of mesos might have a third set of tuningset. This could be accomplished within mesos IFF mesos were aware of all potential cgroups my kernel supports, AND all my frameworks had ways of running through mesos, but neither one of those is a guaranteed assumption. My ask here is that the intended behavior is clarified for when a cgroup is present on a system, but the version of mesos running is not aware of how to use such a cgroup (blkio or maybe https://issues.apache.org/jira/browse/MESOS-4424 or something else even). > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a > different hierarchy. This gradually become not true with unified cgroup > hierarchy introduced in kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. But we don't plan to support > cgroup v2 in this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203418#comment-15203418 ] haosdent commented on MESOS-4697: - [~idownes] We public the design doc in https://docs.google.com/document/d/1rAAzymtY5tcXY9X-Ryz6tEFeWA1_VBhnFYoE7M2kbvk/edit?usp=sharing , looking forward your comments and suggestions. > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a different hierarchy. > This gradually become not true with unified cgroup hierarchy introduced in > kernel 3.16([The unified control group hierarchy in > 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|]). > Also, on some popular linux distributions, some subsystems are co-mounted > within the same hierarchy (e.g., net_cls and net_prio, cpu and cpuacct). It > becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator by introduce a Subsystem abstraction. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172320#comment-15172320 ] Jie Yu commented on MESOS-4697: --- [~idownes] Thanks for the comment. There'll be design doc for this which will list the motivations, and how it'll be implemented, and how it can be extended. Will send to the dev list to get feedback. > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > Linux introduce the unified cgroup hierarchy since 3.16 [The unified control > group hierarchy in 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|] > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a different hierarchy. > This gradually become not true with unified cgroup hierarchy introduced in > kernel 3.16. Also, on some popular linux distributions, some subsystems are > co-mounted within the same hierarchy (e.g., net_cls and net_prio, cpu and > cpuacct). It becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator (e.g., introduce a Subsystem abstraction?). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MESOS-4697) Consolidate cgroup isolators into one single isolator.
[ https://issues.apache.org/jira/browse/MESOS-4697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172285#comment-15172285 ] Ian Downes commented on MESOS-4697: --- Those are valid reasons to consider changing the current code but can you talk more specifically about how a consolidated isolator would address, or deliberately not address, the original motivations? composability, extensibility, etc. Can you confirm this would just be for isolation that manipulates cgroups? How would it be extensible? How would different functionality be selected, e.g., if there's a single cgroups isolator that includes net_cls but the operator did not want to enable, instead selecting something like the current network/port_mapping isolator? Could (1) not be addressed perhaps by composition with a generic cgroups isolator? and (2) could be addressed by fixing the existing somewhat rigid isolator <-> controller mapping while still preserving the separation of resource isolation, e.g., cpu and cpuacct naturally belong together. What hierarchy configuration(s) would the new isolator support? Would it be a new isolator or would it replace the existing isolators? > Consolidate cgroup isolators into one single isolator. > -- > > Key: MESOS-4697 > URL: https://issues.apache.org/jira/browse/MESOS-4697 > Project: Mesos > Issue Type: Epic >Reporter: Jie Yu >Assignee: haosdent > Attachments: cgroup_v2.pdf > > > Linux introduce the unified cgroup hierarchy since 3.16 [The unified control > group hierarchy in 3.16|https://lwn.net/Articles/601840/], > [cgroup-v2|https://github.com/torvalds/linux/blob/master/Documentation/cgroup-v2.txt|] > There are two motivations for this: > 1) It's very verbose to add a new isolator. For cgroup isolators (e.g., cpu, > mem, net_cls, etc.), many of the logics are the same. We are currently > duplicating a lot of the code. > 2) Initially, we decided to use a separate isolator for each cgroup subsystem > is because we want each subsystem to be mounted under a different hierarchy. > This gradually become not true with unified cgroup hierarchy introduced in > kernel 3.16. Also, on some popular linux distributions, some subsystems are > co-mounted within the same hierarchy (e.g., net_cls and net_prio, cpu and > cpuacct). It becomes very hard to co-manage a hierarchy by two isolators. > We can still introduce subsystem specific code under the unified cgroup > isolator (e.g., introduce a Subsystem abstraction?). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
