linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Glauber Costa <glommer@parallels.com>
To: Tejun Heo <tj@kernel.org>
Cc: <containers@lists.linux-foundation.org>,
	<cgroups@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Li Zefan <lizefan@huawei.com>, Michal Hocko <mhocko@suse.cz>,
	Peter Zijlstra <peterz@infradead.org>,
	Paul Turner <pjt@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>, Thomas Graf <tgraf@suug.ch>,
	"Serge E. Hallyn" <serue@us.ibm.com>,
	Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
	Neil Horman <nhorman@tuxdriver.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Lennart Poettering <lennart@poettering.net>,
	"Kay Sievers" <kay.sievers@vrfy.org>
Subject: Re: [RFC] cgroup TODOs
Date: Mon, 17 Sep 2012 12:50:47 +0400	[thread overview]
Message-ID: <5056E467.2090108@parallels.com> (raw)
In-Reply-To: <20120914174329.GD17747@google.com>

On 09/14/2012 09:43 PM, Tejun Heo wrote:
> Hello, Glauber.
> 
> On Fri, Sep 14, 2012 at 12:16:31PM +0400, Glauber Costa wrote:
>> Can we please keep some key userspace guys CCd?
> 
> Yeap, thanks for adding the ccs.
> 
>>> 1. cpu and cpuacct
> ...
>>>   Me, working on it.
>> I can work on it as well if you want. I dealt with it many times in
>> the past, and tried some different approaches, so I am familiar. But
>> if you're already doing it, be my guest...
> 
> I'm trying something minimal which can serve as basis for the actual
> work.  I think I figured it out mostly and will probably post it later
> today.  Will squeak if I get stuck.
> 
>>>   I'll do the cgroup_freezer.  I'm hoping PeterZ or someone who's
>>>   familiar with the code base takes care of cpuset.  Michal, can you
>>>   please take care of memcg?
>>
>> I think this is a pressing problem, yes, but not the only problem with
>> cgroup lock. Even if we restrict its usage to cgroup core, we still can
>> call cgroup functions, which will lock. And then we gain nothing.
> 
> Can you be a bit more specific?
> 
What I mean is that if some operation needs to operate locked, they will
have to lock. Whether or not the locking is called from cgroup core or
not. If the lock is not available outside, people will end up calling a
core function that locks.


>> And the problem is that people need to lock. cgroup_lock is needed
>> because the data you are accessing is protected by it. The way I see it,
>> it is incredible how we were able to revive the BKL in the form of
>> cgroup_lock after we finally manage to successfully get rid of it!
> 
> I wouldn't go as far as comparing it to BKL.
> 
Of course not, since it is not system-wide. But I think the comparison
still holds in spirit...

>> Do you realize this is the exact same thing I proposed in our last
>> round, and you keep screaming saying you wanted something else, right?
>>
>> The only difference is that the discussion at the time started by a
>> forced-comount patch, but that is not the core of the question. For that
>> you are proposing to make sense, the controllers need to be comounted,
>> and at some point we'll have to enforce it. Be it now or in the future.
>> But what to do when they are in fact comounted, I see no difference from
>> what you are saying, and what I said.
> 
> Maybe I misunderstood you or from still talking about forced co-mounts
> more likely you're still misunderstanding.  From what you told PeterZ,
> it seemed like you were thinking that this somehow will get rid of
> differing hierarchies depending on specific controllers and thus will
> help, for example, the optimization issues between cpu and cpuacct.
> Going back to the above example,
> 
>  Unified tree           Controller Y's view
>  controller X's view
> 
>       R                          R
>      / \                        / \
>     A   B                      A   B
>    / \
>   AA AB
> 
> If a task assigned to or resourced tagged with AA, for controller X
> it'll map to AA and for controller Y to A, so we would still need
> css_set, which actually becomes the primary resource tag and may point
> to different subsystem states depending on the specific controller.
> 
> If that is the direction we're headed, forcing co-mounts at this point
> doesn't make any sense.  We'll make things which are possible today
> impossible for quite a while and then restore part of it, which is a
> terrible transition plan.  What we need to do is nudging the current
> users away from practices which hinder implementation of the final
> form and then transition to it gradually.
> 
> If you still don't understand, I don't know what more I can do to
> help.
>

you seem to hear "comount", and think of unified vision, and that is the
reason for this discussion to still be going on. Mounting is all about
the root. And if you comount, hierarchies have the same root.

In your example, the different controllers are comounted. They have not
the same view, but the possible views are restricted to be a subset of
the underlying tree - because they are mounted in the same place, forced
or not.

In a situation like this, it makes all the sense in the world to use the
css_id as a primary identifier, because it will be guaranteed to be the
same. What makes the tree overly flexible, is that you can have multiple
roots, starting in multiple places, with arbitrary topologies downwards.

If you still don't understand, I don't know what more I can do to help.



  reply	other threads:[~2012-09-17  8:54 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-13 20:58 [RFC] cgroup TODOs Tejun Heo
2012-09-14  9:04 ` Mike Galbraith
2012-09-14 17:17   ` Tejun Heo
2012-09-14  9:10 ` Daniel P. Berrange
2012-09-14 13:58   ` Vivek Goyal
2012-09-14 19:29     ` Tejun Heo
2012-09-14 21:51       ` Kay Sievers
     [not found] ` <5052E7DF.7040000@parallels.com>
2012-09-14  9:12   ` Li Zefan
2012-09-14 11:22     ` Peter Zijlstra
2012-09-14 17:59     ` Tejun Heo
2012-09-14 18:23       ` Peter Zijlstra
2012-09-14 18:33         ` Tejun Heo
2012-09-14 17:43   ` Tejun Heo
2012-09-17  8:50     ` Glauber Costa [this message]
2012-09-17 17:21       ` Tejun Heo
2012-09-14 11:15 ` Peter Zijlstra
2012-09-14 12:54   ` Daniel P. Berrange
2012-09-14 17:53   ` Tejun Heo
2012-09-14 14:25 ` Vivek Goyal
2012-09-14 14:53   ` Peter Zijlstra
2012-09-14 15:14     ` Vivek Goyal
2012-09-14 21:57       ` Tejun Heo
2012-09-17 15:27         ` Vivek Goyal
2012-09-18 18:08         ` Vivek Goyal
2012-09-14 21:39   ` Tejun Heo
2012-09-17 15:05     ` Vivek Goyal
2012-09-17 16:40       ` Tejun Heo
2012-09-14 15:03 ` Michal Hocko
2012-09-19 14:02   ` Michal Hocko
2012-09-19 14:03     ` [PATCH 2.6.32] memcg: warn on deeper hierarchies with use_hierarchy==0 Michal Hocko
2012-09-19 19:38       ` David Rientjes
2012-09-20 13:24         ` Michal Hocko
2012-09-20 22:33           ` David Rientjes
2012-09-21  7:16             ` Michal Hocko
2012-09-19 14:03     ` [PATCH 3.0] " Michal Hocko
2012-09-19 14:05     ` [PATCH 3.2+] " Michal Hocko
2012-09-14 18:07 ` [RFC] cgroup TODOs Vivek Goyal
2012-09-14 18:53   ` Tejun Heo
2012-09-14 19:28     ` Vivek Goyal
2012-09-14 19:44       ` Tejun Heo
2012-09-14 19:49         ` Tejun Heo
2012-09-14 20:39           ` Tejun Heo
2012-09-17  8:40             ` Glauber Costa
2012-09-17 17:30               ` Tejun Heo
2012-09-17 14:37             ` Vivek Goyal
2012-09-14 18:36 ` Aristeu Rozanski
2012-09-14 18:54   ` Tejun Heo
2012-09-15  2:20   ` Serge E. Hallyn
2012-09-15  9:27     ` Controlling devices and device namespaces Eric W. Biederman
2012-09-15 22:05       ` Serge E. Hallyn
2012-09-16  0:24         ` Eric W. Biederman
2012-09-16  3:31           ` Serge E. Hallyn
2012-09-16 11:21           ` Alan Cox
2012-09-16 11:56             ` Eric W. Biederman
2012-09-16 12:17               ` Eric W. Biederman
2012-09-16 13:32                 ` Serge Hallyn
2012-09-16 14:23                   ` Eric W. Biederman
2012-09-16 16:13                     ` Alan Cox
2012-09-16 17:49                       ` Eric W. Biederman
2012-09-16 16:15                     ` Serge Hallyn
2012-09-16 16:53                       ` Eric W. Biederman
2012-09-16  8:19   ` [RFC] cgroup TODOs James Bottomley
2012-09-16 14:41     ` Eric W. Biederman
2012-09-17 13:21     ` Aristeu Rozanski
2012-09-14 22:03 ` Dhaval Giani
2012-09-14 22:06   ` Tejun Heo
2012-09-20  1:33 ` Andy Lutomirski
2012-09-20 18:26   ` Tejun Heo
2012-09-20 18:39     ` Andy Lutomirski
2012-09-21 21:40 ` Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5056E467.2090108@parallels.com \
    --to=glommer@parallels.com \
    --cc=acme@ghostprotocols.net \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=berrange@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kay.sievers@vrfy.org \
    --cc=lennart@poettering.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=mhocko@suse.cz \
    --cc=mingo@redhat.com \
    --cc=nhorman@tuxdriver.com \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=serue@us.ibm.com \
    --cc=tgraf@suug.ch \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).