On Thu, 2016-04-14 at 15:57 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Thu, Apr 14, 2016 at 08:07:37AM +0200, Mike Galbraith wrote:
> > Let /foo be an exclusive cpuset containing exclusive subset bar.
> > How can any task acquire set foo affinity if B really really
> > applies? My box calls
On Thu, 2016-04-14 at 15:57 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Thu, Apr 14, 2016 at 08:07:37AM +0200, Mike Galbraith wrote:
> > Let /foo be an exclusive cpuset containing exclusive subset bar.
> > How can any task acquire set foo affinity if B really really
> > applies? My box calls
Hello, Mike.
On Thu, Apr 14, 2016 at 08:07:37AM +0200, Mike Galbraith wrote:
> Let /foo be an exclusive cpuset containing exclusive subset bar.
> How can any task acquire set foo affinity if B really really
> applies? My box calls me a dummy if I try to create a "proper" home
> for tasks, one
Hello, Mike.
On Thu, Apr 14, 2016 at 08:07:37AM +0200, Mike Galbraith wrote:
> Let /foo be an exclusive cpuset containing exclusive subset bar.
> How can any task acquire set foo affinity if B really really
> applies? My box calls me a dummy if I try to create a "proper" home
> for tasks, one
On Wed, 2016-04-13 at 11:59 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Wed, Apr 13, 2016 at 09:43:01AM +0200, Mike Galbraith wrote:
> > > The cost is part aesthetical and part practical. While less
> > > elegant
> > > than tree of uniform objects, it seems a stretch to call internal
> > > /
>
On Wed, 2016-04-13 at 11:59 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Wed, Apr 13, 2016 at 09:43:01AM +0200, Mike Galbraith wrote:
> > > The cost is part aesthetical and part practical. While less
> > > elegant
> > > than tree of uniform objects, it seems a stretch to call internal
> > > /
>
On Wed, 2016-04-13 at 11:59 -0400, Tejun Heo wrote:
> Are you saying that you're aware that google or another big outfit is
> making active use of internal tasks competing against sibling cgroups
> for proportional CPU distribution? If so, can you please be more
> specific?
What I'm aware of is
On Wed, 2016-04-13 at 11:59 -0400, Tejun Heo wrote:
> Are you saying that you're aware that google or another big outfit is
> making active use of internal tasks competing against sibling cgroups
> for proportional CPU distribution? If so, can you please be more
> specific?
What I'm aware of is
Hello, Mike.
On Wed, Apr 13, 2016 at 09:43:01AM +0200, Mike Galbraith wrote:
> > The cost is part aesthetical and part practical. While less elegant
> > than tree of uniform objects, it seems a stretch to call internal /
> > leaf node distinction broken especially given that the model is
> >
Hello, Mike.
On Wed, Apr 13, 2016 at 09:43:01AM +0200, Mike Galbraith wrote:
> > The cost is part aesthetical and part practical. While less elegant
> > than tree of uniform objects, it seems a stretch to call internal /
> > leaf node distinction broken especially given that the model is
> >
On Tue, 2016-04-12 at 18:29 -0400, Tejun Heo wrote:
> Hello, Peter.
>
> On Sat, Apr 09, 2016 at 03:39:17PM +0200, Peter Zijlstra wrote:
> > > While the separate buckets and entities model may not be as elegant as
> > > tree of uniform objects, it is far from uncommon and more robust when
> > >
On Tue, 2016-04-12 at 18:29 -0400, Tejun Heo wrote:
> Hello, Peter.
>
> On Sat, Apr 09, 2016 at 03:39:17PM +0200, Peter Zijlstra wrote:
> > > While the separate buckets and entities model may not be as elegant as
> > > tree of uniform objects, it is far from uncommon and more robust when
> > >
Hello, Peter.
On Sat, Apr 09, 2016 at 03:39:17PM +0200, Peter Zijlstra wrote:
> > While the separate buckets and entities model may not be as elegant as
> > tree of uniform objects, it is far from uncommon and more robust when
> > dealing with different types of objects.
>
> The graph does not
Hello, Peter.
On Sat, Apr 09, 2016 at 03:39:17PM +0200, Peter Zijlstra wrote:
> > While the separate buckets and entities model may not be as elegant as
> > tree of uniform objects, it is far from uncommon and more robust when
> > dealing with different types of objects.
>
> The graph does not
On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote:
> > Yes, I'm familiar with the problem; but simply mandating leaf only nodes
> > is not a solution, for the very simple fact that there are tasks in the
> > root cgroup that cannot ever be moved out, so we _must_ be able to deal
> > with
On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote:
> > Yes, I'm familiar with the problem; but simply mandating leaf only nodes
> > is not a solution, for the very simple fact that there are tasks in the
> > root cgroup that cannot ever be moved out, so we _must_ be able to deal
> > with
On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote:
> > > Widely diverging from
> > > CPU's behavior, IO grouped all internal tasks into an internal leaf
> > > node and used to assign a fixed weight to it.
> >
> > That's just plain broken... That is not how a proportional weight based
> >
On Fri, Apr 08, 2016 at 04:11:35PM -0400, Tejun Heo wrote:
> > > Widely diverging from
> > > CPU's behavior, IO grouped all internal tasks into an internal leaf
> > > node and used to assign a fixed weight to it.
> >
> > That's just plain broken... That is not how a proportional weight based
> >
On Fri, 2016-04-08 at 16:11 -0400, Tejun Heo wrote:
> > That's just plain broken... That is not how a proportional weight based
> > hierarchical controller works.
>
> That's a strong statement. When the hierarchy is composed of
> equivalent objects as in CPU, not distinguishing internal and
On Fri, 2016-04-08 at 16:11 -0400, Tejun Heo wrote:
> > That's just plain broken... That is not how a proportional weight based
> > hierarchical controller works.
>
> That's a strong statement. When the hierarchy is composed of
> equivalent objects as in CPU, not distinguishing internal and
Hello, Peter.
On Thu, Apr 07, 2016 at 10:25:42PM +0200, Peter Zijlstra wrote:
> > The balkanization was no coincidence either. Tasks and cgroups are
> > different types of entities and don't have the same control knobs or
> > follow the same lifetime rules. For absolute limits, it isn't clear
>
Hello, Peter.
On Thu, Apr 07, 2016 at 10:25:42PM +0200, Peter Zijlstra wrote:
> > The balkanization was no coincidence either. Tasks and cgroups are
> > different types of entities and don't have the same control knobs or
> > follow the same lifetime rules. For absolute limits, it isn't clear
>
On Thu, 2016-04-07 at 16:23 -0400, Johannes Weiner wrote:
> Mike, is that the one you referred to with one group per customer
> account? If so, would you have a pointer to where you outline it?
The usage I loosely outlined, I did in this thread. All of the gory
details I do not have, do not
On Thu, 2016-04-07 at 16:23 -0400, Johannes Weiner wrote:
> Mike, is that the one you referred to with one group per customer
> account? If so, would you have a pointer to where you outline it?
The usage I loosely outlined, I did in this thread. All of the gory
details I do not have, do not
On Thu, Apr 07, 2016 at 03:45:55PM -0400, Tejun Heo wrote:
> Hello, Peter.
>
> On Thu, Apr 07, 2016 at 10:08:33AM +0200, Peter Zijlstra wrote:
> > On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> > > So it was a nice cleanup for the memory controller and I believe the
> > > IO
On Thu, Apr 07, 2016 at 03:45:55PM -0400, Tejun Heo wrote:
> Hello, Peter.
>
> On Thu, Apr 07, 2016 at 10:08:33AM +0200, Peter Zijlstra wrote:
> > On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> > > So it was a nice cleanup for the memory controller and I believe the
> > > IO
On Thu, Apr 07, 2016 at 09:31:27PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 03:04:24PM -0400, Johannes Weiner wrote:
>
> > All this means here is that if you want to change the shares allocated
> > to the tasks in R (or then L) you have to be explicit about it and
> > update the
On Thu, Apr 07, 2016 at 09:31:27PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 03:04:24PM -0400, Johannes Weiner wrote:
>
> > All this means here is that if you want to change the shares allocated
> > to the tasks in R (or then L) you have to be explicit about it and
> > update the
Hello, Peter.
On Thu, Apr 07, 2016 at 10:08:33AM +0200, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> > So it was a nice cleanup for the memory controller and I believe the
> > IO controller as well. I'd be curious how it'd be a problem for CPU?
>
>
Hello, Peter.
On Thu, Apr 07, 2016 at 10:08:33AM +0200, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> > So it was a nice cleanup for the memory controller and I believe the
> > IO controller as well. I'd be curious how it'd be a problem for CPU?
>
>
On Thu, Apr 07, 2016 at 03:04:24PM -0400, Johannes Weiner wrote:
> All this means here is that if you want to change the shares allocated
> to the tasks in R (or then L) you have to be explicit about it and
> update the weight configuration in L.
Updating the weight of L for every task spawned
On Thu, Apr 07, 2016 at 03:04:24PM -0400, Johannes Weiner wrote:
> All this means here is that if you want to change the shares allocated
> to the tasks in R (or then L) you have to be explicit about it and
> update the weight configuration in L.
Updating the weight of L for every task spawned
On Thu, Apr 07, 2016 at 10:28:10AM +0200, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> > There was a lot of back and forth whether we should add a second set
> > of knobs just to control the local tasks separately from the subtree,
> > but ended up
On Thu, Apr 07, 2016 at 10:28:10AM +0200, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> > There was a lot of back and forth whether we should add a second set
> > of knobs just to control the local tasks separately from the subtree,
> > but ended up
On Thu, Apr 07, 2016 at 05:28:24AM -0400, Johannes Weiner wrote:
> Hm? The root group can always contain tasks. It's not the only thing
> the root is exempt from, it can't control any resources either:
it does in fact control resouces; the hierarchy directly affects the
proportional distribution
On Thu, Apr 07, 2016 at 05:28:24AM -0400, Johannes Weiner wrote:
> Hm? The root group can always contain tasks. It's not the only thing
> the root is exempt from, it can't control any resources either:
it does in fact control resouces; the hierarchy directly affects the
proportional distribution
On Thu, Apr 07, 2016 at 10:08:33AM +0200, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> > On Thu, Apr 07, 2016 at 08:45:49AM +0200, Peter Zijlstra wrote:
> > > So I recently got made aware of the fact that cgroupv2 doesn't allow
> > > tasks to be
On Thu, Apr 07, 2016 at 10:08:33AM +0200, Peter Zijlstra wrote:
> On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> > On Thu, Apr 07, 2016 at 08:45:49AM +0200, Peter Zijlstra wrote:
> > > So I recently got made aware of the fact that cgroupv2 doesn't allow
> > > tasks to be
On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> There was a lot of back and forth whether we should add a second set
> of knobs just to control the local tasks separately from the subtree,
> but ended up concluding that the situation can be expressed more
> clearly by creating
On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> There was a lot of back and forth whether we should add a second set
> of knobs just to control the local tasks separately from the subtree,
> but ended up concluding that the situation can be expressed more
> clearly by creating
On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> On Thu, Apr 07, 2016 at 08:45:49AM +0200, Peter Zijlstra wrote:
> > So I recently got made aware of the fact that cgroupv2 doesn't allow
> > tasks to be associated with !leaf cgroups, this is yet another
> > capability of
On Thu, Apr 07, 2016 at 03:35:47AM -0400, Johannes Weiner wrote:
> On Thu, Apr 07, 2016 at 08:45:49AM +0200, Peter Zijlstra wrote:
> > So I recently got made aware of the fact that cgroupv2 doesn't allow
> > tasks to be associated with !leaf cgroups, this is yet another
> > capability of
On Thu, 2016-04-07 at 03:35 -0400, Johannes Weiner wrote:
> On Thu, Apr 07, 2016 at 08:45:49AM +0200, Peter Zijlstra wrote:
> > So I recently got made aware of the fact that cgroupv2 doesn't
> > allow
> > tasks to be associated with !leaf cgroups, this is yet another
> > capability of cpu-cgroup
On Thu, 2016-04-07 at 03:35 -0400, Johannes Weiner wrote:
> On Thu, Apr 07, 2016 at 08:45:49AM +0200, Peter Zijlstra wrote:
> > So I recently got made aware of the fact that cgroupv2 doesn't
> > allow
> > tasks to be associated with !leaf cgroups, this is yet another
> > capability of cpu-cgroup
On Thu, Apr 07, 2016 at 08:45:49AM +0200, Peter Zijlstra wrote:
> So I recently got made aware of the fact that cgroupv2 doesn't allow
> tasks to be associated with !leaf cgroups, this is yet another
> capability of cpu-cgroup you've destroyed.
May I ask how you are using that?
The behavior for
On Thu, Apr 07, 2016 at 08:45:49AM +0200, Peter Zijlstra wrote:
> So I recently got made aware of the fact that cgroupv2 doesn't allow
> tasks to be associated with !leaf cgroups, this is yet another
> capability of cpu-cgroup you've destroyed.
May I ask how you are using that?
The behavior for
So I recently got made aware of the fact that cgroupv2 doesn't allow
tasks to be associated with !leaf cgroups, this is yet another
capability of cpu-cgroup you've destroyed.
At this point I really don't see why I should spend another second
considering anything v2.
So full NAK and stop
So I recently got made aware of the fact that cgroupv2 doesn't allow
tasks to be associated with !leaf cgroups, this is yet another
capability of cpu-cgroup you've destroyed.
At this point I really don't see why I should spend another second
considering anything v2.
So full NAK and stop
On Wed, Apr 06, 2016 at 05:53:07PM -0400, Tejun Heo wrote:
> Can you list applications which make use of CLONE_VM without
> CLONE_THREAD?
I ran into one two years ago or so; I forgot what it was, but it made
perf misbehave because we too had assumed this not to happen.
Eventually it turned out
On Wed, Apr 06, 2016 at 05:53:07PM -0400, Tejun Heo wrote:
> Can you list applications which make use of CLONE_VM without
> CLONE_THREAD?
I ran into one two years ago or so; I forgot what it was, but it made
perf misbehave because we too had assumed this not to happen.
Eventually it turned out
On Wed, 2016-04-06 at 20:00 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Sun, Mar 13, 2016 at 06:40:35PM +0100, Mike Galbraith wrote:
> > On Sun, 2016-03-13 at 11:00 -0400, Tejun Heo wrote:
> > > Let's say there is an application which wants to manage resource
> > > distributions across its
On Wed, 2016-04-06 at 20:00 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Sun, Mar 13, 2016 at 06:40:35PM +0100, Mike Galbraith wrote:
> > On Sun, 2016-03-13 at 11:00 -0400, Tejun Heo wrote:
> > > Let's say there is an application which wants to manage resource
> > > distributions across its
Hello, Mike.
On Sun, Mar 13, 2016 at 06:40:35PM +0100, Mike Galbraith wrote:
> On Sun, 2016-03-13 at 11:00 -0400, Tejun Heo wrote:
> > Let's say there is an application which wants to manage resource
> > distributions across its multiple threadpools in a hierarchical way.
> > With cgroupfs
Hello, Mike.
On Sun, Mar 13, 2016 at 06:40:35PM +0100, Mike Galbraith wrote:
> On Sun, 2016-03-13 at 11:00 -0400, Tejun Heo wrote:
> > Let's say there is an application which wants to manage resource
> > distributions across its multiple threadpools in a hierarchical way.
> > With cgroupfs
Hello, Michal.
Sorry about the delay.
On Tue, Mar 15, 2016 at 06:21:36PM +0100, Michal Hocko wrote:
> While I agree that per-thread granularity is no fun for controllers
> which operate on different than task_struct entities (like memory cgroup
> controller) but I am afraid that all the
Hello, Michal.
Sorry about the delay.
On Tue, Mar 15, 2016 at 06:21:36PM +0100, Michal Hocko wrote:
> While I agree that per-thread granularity is no fun for controllers
> which operate on different than task_struct entities (like memory cgroup
> controller) but I am afraid that all the
Hello, Peter.
Sorry about the delay.
On Mon, Mar 14, 2016 at 12:30:13PM +0100, Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 10:41:18AM -0500, Tejun Heo wrote:
> > * A rgroup is a cgroup which is invisible on and transparent to the
> > system-level cgroupfs interface.
> >
> > * A rgroup can
Hello, Peter.
Sorry about the delay.
On Mon, Mar 14, 2016 at 12:30:13PM +0100, Peter Zijlstra wrote:
> On Fri, Mar 11, 2016 at 10:41:18AM -0500, Tejun Heo wrote:
> > * A rgroup is a cgroup which is invisible on and transparent to the
> > system-level cgroupfs interface.
> >
> > * A rgroup can
On Fri 11-03-16 10:41:18, Tejun Heo wrote:
> Hello,
>
> This patchset extends cgroup v2 to support rgroup (resource group) for
> in-process hierarchical resource control and implements PRIO_RGRP for
> setpriority(2) on top to allow in-process hierarchical CPU cycle
> control in a seamless way.
>
On Fri 11-03-16 10:41:18, Tejun Heo wrote:
> Hello,
>
> This patchset extends cgroup v2 to support rgroup (resource group) for
> in-process hierarchical resource control and implements PRIO_RGRP for
> setpriority(2) on top to allow in-process hierarchical CPU cycle
> control in a seamless way.
>
On Fri, Mar 11, 2016 at 10:41:18AM -0500, Tejun Heo wrote:
> * A rgroup is a cgroup which is invisible on and transparent to the
> system-level cgroupfs interface.
>
> * A rgroup can be created by specifying CLONE_NEWRGRP flag, along with
> CLONE_THREAD, during clone(2). A new rgroup is
On Fri, Mar 11, 2016 at 10:41:18AM -0500, Tejun Heo wrote:
> * A rgroup is a cgroup which is invisible on and transparent to the
> system-level cgroupfs interface.
>
> * A rgroup can be created by specifying CLONE_NEWRGRP flag, along with
> CLONE_THREAD, during clone(2). A new rgroup is
On Sun, 2016-03-13 at 11:00 -0400, Tejun Heo wrote:
> There can be use cases where building cpu resource hierarchy which is
> completely alien to how the rest of the system is organized is useful.
Well, from my POV it's the "process" oriented thingy that's the alien,
and one that wants to meet
On Sun, 2016-03-13 at 11:00 -0400, Tejun Heo wrote:
> There can be use cases where building cpu resource hierarchy which is
> completely alien to how the rest of the system is organized is useful.
Well, from my POV it's the "process" oriented thingy that's the alien,
and one that wants to meet
On Sun, 2016-03-13 at 11:00 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Sat, Mar 12, 2016 at 07:26:59AM +0100, Mike Galbraith wrote:
> > Hrm. You're showing that per-thread groups can coexist just fine,
> > which is good given need and usage exists today out in the wild. Why
> > do such
On Sun, 2016-03-13 at 11:00 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Sat, Mar 12, 2016 at 07:26:59AM +0100, Mike Galbraith wrote:
> > Hrm. You're showing that per-thread groups can coexist just fine,
> > which is good given need and usage exists today out in the wild. Why
> > do such
Hello, Mike.
On Sat, Mar 12, 2016 at 07:26:59AM +0100, Mike Galbraith wrote:
> Hrm. You're showing that per-thread groups can coexist just fine,
> which is good given need and usage exists today out in the wild. Why
> do such groups have to be invisible with a unique interface though?
I tried
Hello, Mike.
On Sat, Mar 12, 2016 at 07:26:59AM +0100, Mike Galbraith wrote:
> Hrm. You're showing that per-thread groups can coexist just fine,
> which is good given need and usage exists today out in the wild. Why
> do such groups have to be invisible with a unique interface though?
I tried
Hello, Ingo.
On Sat, Mar 12, 2016 at 06:13:18PM +0100, Ingo Molnar wrote:
> > BTW, within the scheduler, "process" does not exist. [...]
>
> Yes, and that's very fundamental.
I'll go into this part later.
> And I see that many bits of the broken 'v2' cgroups ABI already snuck into
> the
>
Hello, Ingo.
On Sat, Mar 12, 2016 at 06:13:18PM +0100, Ingo Molnar wrote:
> > BTW, within the scheduler, "process" does not exist. [...]
>
> Yes, and that's very fundamental.
I'll go into this part later.
> And I see that many bits of the broken 'v2' cgroups ABI already snuck into
> the
>
* Mike Galbraith wrote:
> On Sat, 2016-03-12 at 07:26 +0100, Mike Galbraith wrote:
> > On Fri, 2016-03-11 at 10:41 -0500, Tejun Heo wrote:
> > > Hello,
> > >
> > > This patchset extends cgroup v2 to support rgroup (resource group) for
> > > in-process hierarchical
* Mike Galbraith wrote:
> On Sat, 2016-03-12 at 07:26 +0100, Mike Galbraith wrote:
> > On Fri, 2016-03-11 at 10:41 -0500, Tejun Heo wrote:
> > > Hello,
> > >
> > > This patchset extends cgroup v2 to support rgroup (resource group) for
> > > in-process hierarchical resource control and
On Sat, 2016-03-12 at 07:26 +0100, Mike Galbraith wrote:
> On Fri, 2016-03-11 at 10:41 -0500, Tejun Heo wrote:
> > Hello,
> >
> > This patchset extends cgroup v2 to support rgroup (resource group) for
> > in-process hierarchical resource control and implements PRIO_RGRP for
> > setpriority(2) on
On Sat, 2016-03-12 at 07:26 +0100, Mike Galbraith wrote:
> On Fri, 2016-03-11 at 10:41 -0500, Tejun Heo wrote:
> > Hello,
> >
> > This patchset extends cgroup v2 to support rgroup (resource group) for
> > in-process hierarchical resource control and implements PRIO_RGRP for
> > setpriority(2) on
On Fri, 2016-03-11 at 10:41 -0500, Tejun Heo wrote:
> Hello,
>
> This patchset extends cgroup v2 to support rgroup (resource group) for
> in-process hierarchical resource control and implements PRIO_RGRP for
> setpriority(2) on top to allow in-process hierarchical CPU cycle
> control in a
On Fri, 2016-03-11 at 10:41 -0500, Tejun Heo wrote:
> Hello,
>
> This patchset extends cgroup v2 to support rgroup (resource group) for
> in-process hierarchical resource control and implements PRIO_RGRP for
> setpriority(2) on top to allow in-process hierarchical CPU cycle
> control in a
Hello,
This patchset extends cgroup v2 to support rgroup (resource group) for
in-process hierarchical resource control and implements PRIO_RGRP for
setpriority(2) on top to allow in-process hierarchical CPU cycle
control in a seamless way.
cgroup v1 allowed putting threads of a process in
Hello,
This patchset extends cgroup v2 to support rgroup (resource group) for
in-process hierarchical resource control and implements PRIO_RGRP for
setpriority(2) on top to allow in-process hierarchical CPU cycle
control in a seamless way.
cgroup v1 allowed putting threads of a process in
78 matches
Mail list logo