On Thu, Sep 6, 2012 at 5:11 PM, Paul Turner wrote:
> On Thu, Sep 6, 2012 at 1:46 PM, Tejun Heo wrote:
>> Hello,
>>
>> cc'ing Dhaval and Frederic. They were interested in the subject
>> before and Dhaval was pretty vocal about cpuacct having a separate
>> hierarchy (or at least granularity).
>
>
Hello, Glauber.
On Thu, Sep 6, 2012 at 3:39 PM, Glauber Costa wrote:
> Yes, please.
>
> While you rightfully claim that you explained it a couple of times, it
> all seems to be quite fuzzy. I don't blame it on you: the current state
> of the interface leads to this.
Heh, I drank two cups of coff
On 09/07/2012 12:38 AM, Tejun Heo wrote:
> Hello, Peter, Glauber.
>
> (I'm gonna write up cgroup core todos which should explain / address
> this issue too. ATM I'm a bit overwhelmed with stuff accumulated
> while traveling.)
>
Yes, please.
While you rightfully claim that you explained it a co
On 09/07/2012 01:11 AM, Paul Turner wrote:
> On Thu, Sep 6, 2012 at 1:46 PM, Tejun Heo wrote:
>> Hello,
>>
>> cc'ing Dhaval and Frederic. They were interested in the subject
>> before and Dhaval was pretty vocal about cpuacct having a separate
>> hierarchy (or at least granularity).
>
> Really?
On Thu, Sep 6, 2012 at 1:46 PM, Tejun Heo wrote:
> Hello,
>
> cc'ing Dhaval and Frederic. They were interested in the subject
> before and Dhaval was pretty vocal about cpuacct having a separate
> hierarchy (or at least granularity).
Really? Time just has _not_ borne out this use-case. I'll le
Hello,
cc'ing Dhaval and Frederic. They were interested in the subject
before and Dhaval was pretty vocal about cpuacct having a separate
hierarchy (or at least granularity).
On Wed, Sep 05, 2012 at 12:04:47PM +0200, Peter Zijlstra wrote:
> > cpuacct is rather unique tho. I think it's gonna be
Hello, Peter, Glauber.
(I'm gonna write up cgroup core todos which should explain / address
this issue too. ATM I'm a bit overwhelmed with stuff accumulated
while traveling.)
On Wed, Sep 05, 2012 at 12:20:53PM +0200, Peter Zijlstra wrote:
> But I don't really see the point though, this kind of i
On Wed, 2012-09-05 at 13:31 +0400, Glauber Costa wrote:
>
> You wouldn't have to do more than one hierarchy walks for that. What
> Tejun seems to want, is the ability to not have a particular controller
> at some point in the tree. But if they exist, they are always together.
Right, but the acco
On Wed, 2012-09-05 at 02:32 -0700, Tejun Heo wrote:
> Hey, again.
>
> On Wed, Sep 05, 2012 at 11:06:33AM +0200, Peter Zijlstra wrote:
> > Doing all this runtime is just going to make the mess even bigger,
> > because now we have to deal with even more stupid cases.
> >
> > So either we go and try
On Wed, Sep 05, 2012 at 01:48:30PM +0400, Glauber Costa wrote:
> > Nope, as I wrote in the other reply,
>
> Would you mind, then, stopping for a moment and telling us what it is,
> then, that you envision?
I thought I already explained it a couple times in this thread (also
in the big thread fro
On 09/05/2012 01:45 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Sep 05, 2012 at 01:31:56PM +0400, Glauber Costa wrote:
>>> > > I simply don't want to have to do two (or more) hierarchy walks for
>>> > > accounting on every schedule event, all that pointer chasing is stupidly
>>> > > expensive.
>> >
Hello,
On Wed, Sep 05, 2012 at 01:31:56PM +0400, Glauber Costa wrote:
> > I simply don't want to have to do two (or more) hierarchy walks for
> > accounting on every schedule event, all that pointer chasing is stupidly
> > expensive.
>
> You wouldn't have to do more than one hierarchy walks for t
On 09/05/2012 01:26 PM, Peter Zijlstra wrote:
> On Wed, 2012-09-05 at 13:12 +0400, Glauber Costa wrote:
>> On 09/05/2012 01:11 PM, Tejun Heo wrote:
>>> Hello, Peter.
>>>
>>> On Wed, Sep 05, 2012 at 11:06:33AM +0200, Peter Zijlstra wrote:
*confused* I always thought that was exactly what you me
On 09/05/2012 01:19 PM, Tejun Heo wrote:
> On Wed, Sep 05, 2012 at 01:12:34PM +0400, Glauber Costa wrote:
>>> No, I never counted out differing granularity.
>>
>> Can you elaborate on which interface do you envision to make it work?
>> They will clearly be mounted in the same hierarchy, or as said
Hey, again.
On Wed, Sep 05, 2012 at 11:06:33AM +0200, Peter Zijlstra wrote:
> Doing all this runtime is just going to make the mess even bigger,
> because now we have to deal with even more stupid cases.
>
> So either we go and try to contain this mess as proposed by Glauber or
> we go delete con
On Wed, 2012-09-05 at 13:12 +0400, Glauber Costa wrote:
> On 09/05/2012 01:11 PM, Tejun Heo wrote:
> > Hello, Peter.
> >
> > On Wed, Sep 05, 2012 at 11:06:33AM +0200, Peter Zijlstra wrote:
> >> *confused* I always thought that was exactly what you meant with unified
> >> hierarchy.
> >
> > No, I
Hey,
On Wed, Sep 05, 2012 at 11:07:21AM +0200, Peter Zijlstra wrote:
> Glauber, the other approach is sending a patch that doesn't touch
> cgroup.c but only the controllers and I'll merge it regardless of what
> tj thinks.
>
> We need some movement here.
Peter, I don't think the proposed patch i
On Wed, Sep 05, 2012 at 01:12:34PM +0400, Glauber Costa wrote:
> > No, I never counted out differing granularity.
>
> Can you elaborate on which interface do you envision to make it work?
> They will clearly be mounted in the same hierarchy, or as said
> alternatively, comounted.
I'm not sure yet
On 09/05/2012 01:11 PM, Tejun Heo wrote:
> Hello, Peter.
>
> On Wed, Sep 05, 2012 at 11:06:33AM +0200, Peter Zijlstra wrote:
>> *confused* I always thought that was exactly what you meant with unified
>> hierarchy.
>
> No, I never counted out differing granularity.
>
Can you elaborate on which
On Wed, Sep 05, 2012 at 01:06:39PM +0400, Glauber Costa wrote:
> > Heh, this is tricky to describe and I'm not really following what you
> > mean.
>
> Do we really want to start cleaning up all this by changing the
> interface to something that is described as "tricky" ?
The concept is not trick
Hello, Peter.
On Wed, Sep 05, 2012 at 11:06:33AM +0200, Peter Zijlstra wrote:
> *confused* I always thought that was exactly what you meant with unified
> hierarchy.
No, I never counted out differing granularity.
> Doing all this runtime is just going to make the mess even bigger,
> because now
On 09/05/2012 01:07 PM, Tejun Heo wrote:
> Hello, Glauber.
>
> On Wed, Sep 05, 2012 at 12:55:21PM +0400, Glauber Costa wrote:
>>> So, I think it's desirable for all controllers to be able to handle
>>> hierarchies the same way and to have the ability to tag something as
>>> belonging to certain gr
Hello, Glauber.
On Wed, Sep 05, 2012 at 12:55:21PM +0400, Glauber Costa wrote:
> > So, I think it's desirable for all controllers to be able to handle
> > hierarchies the same way and to have the ability to tag something as
> > belonging to certain group in the hierarchy for all controllers but I
On Wed, 2012-09-05 at 11:06 +0200, Peter Zijlstra wrote:
>
> So either we go and try to contain this mess as proposed by Glauber or
> we go delete controllers.. I've had it with this crap.
>
>
Glauber, the other approach is sending a patch that doesn't touch
cgroup.c but only the controllers an
On Wed, 2012-09-05 at 01:47 -0700, Tejun Heo wrote:
> I think this is where we disagree. I didn't mean that all controllers
> should be using exactly the same hierarchy when I was talking about
> unified hierarchy. I do think it's useful and maybe even essential to
> allow differing levels of gra
On 09/05/2012 12:47 PM, Tejun Heo wrote:
> Hello, Glauber.
>
> On Wed, Sep 05, 2012 at 12:35:11PM +0400, Glauber Costa wrote:
>>> As long as cpuacct and cpu are separate, I think it makes sense to
>>> assume that they at least could be at different granularity.
>>
>> If they are comounted, and m
Hello, Glauber.
On Wed, Sep 05, 2012 at 12:35:11PM +0400, Glauber Costa wrote:
> > As long as cpuacct and cpu are separate, I think it makes sense to
> > assume that they at least could be at different granularity.
>
> If they are comounted, and more: forceably comounted, I don't see how to
> c
On 09/05/2012 12:29 PM, Tejun Heo wrote:
> Hello, Glauber.
>
> On Wed, Sep 05, 2012 at 12:17:11PM +0400, Glauber Costa wrote:
>>> Distros can just co-mount them during boot. What's the point of the
>>> config options?
>>
>> Pretty simple. The kernel can't assume the distro did. And then we still
Hello, Glauber.
On Wed, Sep 05, 2012 at 12:17:11PM +0400, Glauber Costa wrote:
> > Distros can just co-mount them during boot. What's the point of the
> > config options?
>
> Pretty simple. The kernel can't assume the distro did. And then we still
> need to pay a stupid big price in the schedule
On 09/05/2012 12:14 PM, Tejun Heo wrote:
> Hello, Glauber.
>
> On Wed, Sep 05, 2012 at 12:03:25PM +0400, Glauber Costa wrote:
>> The goal here is to have distributions to do it, because they tend to
>> have a well defined lifecycle management, much more than upstream. Whoever
>> sets this option,
Hello, Glauber.
On Wed, Sep 05, 2012 at 12:03:25PM +0400, Glauber Costa wrote:
> The goal here is to have distributions to do it, because they tend to
> have a well defined lifecycle management, much more than upstream. Whoever
> sets this option, can coordinate with upstream.
Distros can just co
On 09/05/2012 01:46 AM, Tejun Heo wrote:
> Hello, Glauber.
>
> On Tue, Sep 04, 2012 at 06:18:15PM +0400, Glauber Costa wrote:
>> As we have been extensively discussing, the cost and pain points for cgroups
>> come from many places. But at least one of those is the arbitrary nature of
>> hierarchie
Hello, Glauber.
On Tue, Sep 04, 2012 at 06:18:15PM +0400, Glauber Costa wrote:
> As we have been extensively discussing, the cost and pain points for cgroups
> come from many places. But at least one of those is the arbitrary nature of
> hierarchies. Many people, including at least Tejun and me wo
Hi,
As we have been extensively discussing, the cost and pain points for cgroups
come from many places. But at least one of those is the arbitrary nature of
hierarchies. Many people, including at least Tejun and me would like this to go
away altogether. Problem so far, is breaking compatiblity wit
34 matches
Mail list logo
