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 a
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 ope
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 to
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 ar
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:
> >
> > - tas
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 we co-mingle threads fro
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 reason
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
>grou
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
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 sa
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 loo
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"
> i
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 mar
(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 weren
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
> > i
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 in-cont
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 mea
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 thread
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 "ena
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:
>
> * Thread mode is explici
26 matches
Mail list logo
