On Tue, Mar 21, 2017 at 01:39:58PM +0100, Peter Zijlstra wrote:
>
> And yes, having to consider views is new and a direct consequence of
> this new optional feature. But I don't see how its a problem.
>
So aside from having (RO) links in thread groups for system controllers,
we could also have
On Tue, Mar 21, 2017 at 01:39:58PM +0100, Peter Zijlstra wrote:
>
> And yes, having to consider views is new and a direct consequence of
> this new optional feature. But I don't see how its a problem.
>
So aside from having (RO) links in thread groups for system controllers,
we could also have
On Mon, Mar 13, 2017 at 04:05:44PM -0400, Tejun Heo wrote:
> Hey, Peter. Sorry about the long delay.
No worries; we're all (too) busy.
> > > If we go to thread mode and back to domain mode, the control knobs for
> > > domain controllers don't make sense on the thread part of the tree and
> > >
On Mon, Mar 13, 2017 at 04:05:44PM -0400, Tejun Heo wrote:
> Hey, Peter. Sorry about the long delay.
No worries; we're all (too) busy.
> > > If we go to thread mode and back to domain mode, the control knobs for
> > > domain controllers don't make sense on the thread part of the tree and
> > >
On Mon, 2017-03-13 at 15:26 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> Sorry about the long delay.
>
> On Mon, Feb 13, 2017 at 06:45:07AM +0100, Mike Galbraith wrote:
> > > > So, as long as the depth stays reasonable (single digit or lower),
> > > > what we try to do is keeping tree traversal
On Mon, 2017-03-13 at 15:26 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> Sorry about the long delay.
>
> On Mon, Feb 13, 2017 at 06:45:07AM +0100, Mike Galbraith wrote:
> > > > So, as long as the depth stays reasonable (single digit or lower),
> > > > what we try to do is keeping tree traversal
Hey, Peter. Sorry about the long delay.
On Tue, Feb 14, 2017 at 11:35:41AM +0100, Peter Zijlstra wrote:
> > This is a bit of delta but as I wrote before, at least cpu (and
> > accordingly cpuacct) won't stay purely task-based as we should account
> > for resource consumptions which aren't tied
Hey, Peter. Sorry about the long delay.
On Tue, Feb 14, 2017 at 11:35:41AM +0100, Peter Zijlstra wrote:
> > This is a bit of delta but as I wrote before, at least cpu (and
> > accordingly cpuacct) won't stay purely task-based as we should account
> > for resource consumptions which aren't tied
Hello, Mike.
Sorry about the long delay.
On Mon, Feb 13, 2017 at 06:45:07AM +0100, Mike Galbraith wrote:
> > > So, as long as the depth stays reasonable (single digit or lower),
> > > what we try to do is keeping tree traversal operations aggregated or
> > > located on slow paths. There still
Hello, Mike.
Sorry about the long delay.
On Mon, Feb 13, 2017 at 06:45:07AM +0100, Mike Galbraith wrote:
> > > So, as long as the depth stays reasonable (single digit or lower),
> > > what we try to do is keeping tree traversal operations aggregated or
> > > located on slow paths. There still
On Sun, Feb 12, 2017 at 02:05:44PM +0900, Tejun Heo wrote:
> Hello,
>
> On Fri, Feb 10, 2017 at 06:51:45PM +0100, Peter Zijlstra wrote:
> > Sure, we're past that. This isn't about what memcg can or cannot do.
> > Previous discussions established that controllers come in two shapes:
> >
> > -
On Sun, Feb 12, 2017 at 02:05:44PM +0900, Tejun Heo wrote:
> Hello,
>
> On Fri, Feb 10, 2017 at 06:51:45PM +0100, Peter Zijlstra wrote:
> > Sure, we're past that. This isn't about what memcg can or cannot do.
> > Previous discussions established that controllers come in two shapes:
> >
> > -
On Sun, 2017-02-12 at 07:59 +0100, Mike Galbraith wrote:
> On Sun, 2017-02-12 at 14:05 +0900, Tejun Heo wrote:
>
> > > I think cgroup tree depth is a more significant issue; because of
> > > hierarchy we often do tree walks (uo-to-root or down-to-task).
> > >
> > > So creating elaborate trees is
On Sun, 2017-02-12 at 07:59 +0100, Mike Galbraith wrote:
> On Sun, 2017-02-12 at 14:05 +0900, Tejun Heo wrote:
>
> > > I think cgroup tree depth is a more significant issue; because of
> > > hierarchy we often do tree walks (uo-to-root or down-to-task).
> > >
> > > So creating elaborate trees is
On Sun, 2017-02-12 at 13:16 -0800, Paul Turner wrote:
>
>
> On Thursday, February 9, 2017, Peter Zijlstra wrote:
> > On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote:
> > > The only case that this does not support vs ".threads" would be some
> > > hybrid where
On Sun, 2017-02-12 at 13:16 -0800, Paul Turner wrote:
>
>
> On Thursday, February 9, 2017, Peter Zijlstra wrote:
> > On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote:
> > > The only case that this does not support vs ".threads" would be some
> > > hybrid where we co-mingle threads
On Sun, 2017-02-12 at 14:05 +0900, Tejun Heo wrote:
> > I think cgroup tree depth is a more significant issue; because of
> > hierarchy we often do tree walks (uo-to-root or down-to-task).
> >
> > So creating elaborate trees is something I try not to do.
>
> So, as long as the depth stays
On Sun, 2017-02-12 at 14:05 +0900, Tejun Heo wrote:
> > I think cgroup tree depth is a more significant issue; because of
> > hierarchy we often do tree walks (uo-to-root or down-to-task).
> >
> > So creating elaborate trees is something I try not to do.
>
> So, as long as the depth stays
Hello,
On Fri, Feb 10, 2017 at 06:51:45PM +0100, Peter Zijlstra wrote:
> Sure, we're past that. This isn't about what memcg can or cannot do.
> Previous discussions established that controllers come in two shapes:
>
> - task based controllers; these are build on per task properties and
>
Hello,
On Fri, Feb 10, 2017 at 06:51:45PM +0100, Peter Zijlstra wrote:
> Sure, we're past that. This isn't about what memcg can or cannot do.
> Previous discussions established that controllers come in two shapes:
>
> - task based controllers; these are build on per task properties and
>
On Fri, Feb 10, 2017 at 10:45:08AM -0500, Tejun Heo wrote:
> > > and making subtrees threaded is a
> > > straight-forward extension of that - threaded controllers just see
> > > further into the hierarchy. Adding threaded sub-sections in the
> > > middle is more complex and frankly confusing.
>
On Fri, Feb 10, 2017 at 10:45:08AM -0500, Tejun Heo wrote:
> > > and making subtrees threaded is a
> > > straight-forward extension of that - threaded controllers just see
> > > further into the hierarchy. Adding threaded sub-sections in the
> > > middle is more complex and frankly confusing.
>
Hello,
On Thu, Feb 09, 2017 at 11:29:09AM +0100, Peter Zijlstra wrote:
> Uhm, no. They would see the exact same hierarchy, seeing how there is
> only one tree. They would have different view of it maybe, but I don't
> see how that matters, nor do you explain.
Sure, the base hierarchy is the same
Hello,
On Thu, Feb 09, 2017 at 11:29:09AM +0100, Peter Zijlstra wrote:
> Uhm, no. They would see the exact same hierarchy, seeing how there is
> only one tree. They would have different view of it maybe, but I don't
> see how that matters, nor do you explain.
Sure, the base hierarchy is the same
On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote:
> What are the motivations that you see for forcing this all onto one
> mount-point via .threads sub-tree tags?
So, you wanted rgroup but with /proc interface? I'm afraid it's too
late for that.
Thanks.
--
tejun
On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote:
> What are the motivations that you see for forcing this all onto one
> mount-point via .threads sub-tree tags?
So, you wanted rgroup but with /proc interface? I'm afraid it's too
late for that.
Thanks.
--
tejun
On Thu, 2017-02-09 at 15:47 +0100, Peter Zijlstra wrote:
> On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote:
> > The only case that this does not support vs ".threads" would be some
> > hybrid where we co-mingle threads from different processes (with the
> > processes belonging to the
On Thu, 2017-02-09 at 15:47 +0100, Peter Zijlstra wrote:
> On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote:
> > The only case that this does not support vs ".threads" would be some
> > hybrid where we co-mingle threads from different processes (with the
> > processes belonging to the
On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote:
> The only case that this does not support vs ".threads" would be some
> hybrid where we co-mingle threads from different processes (with the
> processes belonging to the same node in the hierarchy). I'm not aware
> of any usage that
On Thu, Feb 09, 2017 at 05:07:16AM -0800, Paul Turner wrote:
> The only case that this does not support vs ".threads" would be some
> hybrid where we co-mingle threads from different processes (with the
> processes belonging to the same node in the hierarchy). I'm not aware
> of any usage that
On Thu, Feb 2, 2017 at 12:06 PM, Tejun Heo wrote:
> Hello,
>
> This patchset implements cgroup v2 thread mode. It is largely based
> on the discussions that we had at the plumbers last year. Here's the
> rough outline.
>
> * Thread mode is explicitly enabled on a cgroup by
On Thu, Feb 2, 2017 at 12:06 PM, Tejun Heo wrote:
> Hello,
>
> This patchset implements cgroup v2 thread mode. It is largely based
> on the discussions that we had at the plumbers last year. Here's the
> rough outline.
>
> * Thread mode is explicitly enabled on a cgroup by writing "enable"
>
On Wed, Feb 08, 2017 at 06:08:19PM -0500, Tejun Heo wrote:
> (cc'ing Linus and Andrew for visibility)
>
> Hello, Peter.
>
> On Mon, Feb 06, 2017 at 01:49:43PM +0100, Peter Zijlstra wrote:
> > But to me the resource domain is your primary new construct; so it makes
> > more sense to explicitly
On Wed, Feb 08, 2017 at 06:08:19PM -0500, Tejun Heo wrote:
> (cc'ing Linus and Andrew for visibility)
>
> Hello, Peter.
>
> On Mon, Feb 06, 2017 at 01:49:43PM +0100, Peter Zijlstra wrote:
> > But to me the resource domain is your primary new construct; so it makes
> > more sense to explicitly
(cc'ing Linus and Andrew for visibility)
Hello, Peter.
On Mon, Feb 06, 2017 at 01:49:43PM +0100, Peter Zijlstra wrote:
> But to me the resource domain is your primary new construct; so it makes
> more sense to explicitly mark that.
Whether it's new or not isn't the point. Resource domains
(cc'ing Linus and Andrew for visibility)
Hello, Peter.
On Mon, Feb 06, 2017 at 01:49:43PM +0100, Peter Zijlstra wrote:
> But to me the resource domain is your primary new construct; so it makes
> more sense to explicitly mark that.
Whether it's new or not isn't the point. Resource domains
On Fri, Feb 03, 2017 at 03:59:55PM -0500, Tejun Heo wrote:
> Hello, Peter.
>
> On Fri, Feb 03, 2017 at 09:20:48PM +0100, Peter Zijlstra wrote:
> > So my proposal was to do the inverse of what you propose here. Instead
> > of marking special 'thread' subtrees, explicitly mark resource domains
> >
On Fri, Feb 03, 2017 at 03:59:55PM -0500, Tejun Heo wrote:
> Hello, Peter.
>
> On Fri, Feb 03, 2017 at 09:20:48PM +0100, Peter Zijlstra wrote:
> > So my proposal was to do the inverse of what you propose here. Instead
> > of marking special 'thread' subtrees, explicitly mark resource domains
> >
On Thu, Feb 02, 2017 at 04:52:29PM -0500, Tejun Heo wrote:
> > 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
On Thu, Feb 02, 2017 at 04:52:29PM -0500, Tejun Heo wrote:
> > 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
Hello,
On Fri, Feb 03, 2017 at 01:10:21PM -0800, Andy Lutomirski wrote:
> Is this flexible enough for the real-world usecases? For my use case
I can't think of a reason why it won't be. Capability-wise, nothing
is being lost by the interface.
> (if I actually ported over to this), it would
Hello,
On Fri, Feb 03, 2017 at 01:10:21PM -0800, Andy Lutomirski wrote:
> Is this flexible enough for the real-world usecases? For my use case
I can't think of a reason why it won't be. Capability-wise, nothing
is being lost by the interface.
> (if I actually ported over to this), it would
On Thu, Feb 2, 2017 at 1:52 PM, Tejun Heo 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
>> >
On Thu, Feb 2, 2017 at 1:52 PM, Tejun Heo 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
Hello, Peter.
On Fri, Feb 03, 2017 at 09:20:48PM +0100, Peter Zijlstra wrote:
> So my proposal was to do the inverse of what you propose here. Instead
> of marking special 'thread' subtrees, explicitly mark resource domains
> in the tree.
>
> So always allow arbitrary hierarchies and allow
Hello, Peter.
On Fri, Feb 03, 2017 at 09:20:48PM +0100, Peter Zijlstra wrote:
> So my proposal was to do the inverse of what you propose here. Instead
> of marking special 'thread' subtrees, explicitly mark resource domains
> in the tree.
>
> So always allow arbitrary hierarchies and allow
On Thu, Feb 02, 2017 at 03:06:27PM -0500, Tejun Heo wrote:
> Hello,
>
> This patchset implements cgroup v2 thread mode. It is largely based
> on the discussions that we had at the plumbers last year. Here's the
> rough outline.
>
> * Thread mode is explicitly enabled on a cgroup by writing
On Thu, Feb 02, 2017 at 03:06:27PM -0500, Tejun Heo wrote:
> Hello,
>
> This patchset implements cgroup v2 thread mode. It is largely based
> on the discussions that we had at the plumbers last year. Here's the
> rough outline.
>
> * Thread mode is explicitly enabled on a cgroup by writing
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?
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?
On Thu, Feb 2, 2017 at 12:06 PM, Tejun Heo wrote:
> Hello,
>
> This patchset implements cgroup v2 thread mode. It is largely based
> on the discussions that we had at the plumbers last year. Here's the
> rough outline.
I like this, but I have some design questions:
>
> *
On Thu, Feb 2, 2017 at 12:06 PM, Tejun Heo wrote:
> Hello,
>
> This patchset implements cgroup v2 thread mode. It is largely based
> on the discussions that we had at the plumbers last year. Here's the
> rough outline.
I like this, but I have some design questions:
>
> * Thread mode is
Hello,
This patchset implements cgroup v2 thread mode. It is largely based
on the discussions that we had at the plumbers last year. Here's the
rough outline.
* Thread mode is explicitly enabled on a cgroup by writing "enable"
into "cgroup.threads" file. The cgroup shouldn't have any child
Hello,
This patchset implements cgroup v2 thread mode. It is largely based
on the discussions that we had at the plumbers last year. Here's the
rough outline.
* Thread mode is explicitly enabled on a cgroup by writing "enable"
into "cgroup.threads" file. The cgroup shouldn't have any child
54 matches
Mail list logo