lkml.org 
[lkml]   [2012]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHSET cgroup/for-3.8] cpuset: decouple cpuset locking from cgroup core
    On Fri 30-11-12 13:00:36, Glauber Costa wrote:
    > On 11/30/2012 07:21 AM, Kamezawa Hiroyuki wrote:
    > > (2012/11/29 6:34), Tejun Heo wrote:
    > >> Hello, guys.
    > >>
    > >> Depending on cgroup core locking - cgroup_mutex - is messy and makes
    > >> cgroup prone to locking dependency problems. The current code already
    > >> has lock dependency loop - memcg nests get_online_cpus() inside
    > >> cgroup_mutex. cpuset the other way around.
    > >>
    > >> Regardless of the locking details, whatever is protecting cgroup has
    > >> inherently to be something outer to most other locking constructs.
    > >> cgroup calls into a lot of major subsystems which in turn have to
    > >> perform subsystem-specific locking. Trying to nest cgroup
    > >> synchronization inside other locks isn't something which can work
    > >> well.
    > >>
    > >> cgroup now has enough API to allow subsystems to implement their own
    > >> locking and cgroup_mutex is scheduled to be made private to cgroup
    > >> core. This patchset makes cpuset implement its own locking instead of
    > >> relying on cgroup_mutex.
    > >>
    > >> cpuset is rather nasty in this respect. Some of it seems to have come
    > >> from the implementation history - cgroup core grew out of cpuset - but
    > >> big part stems from cpuset's need to migrate tasks to an ancestor
    > >> cgroup when an hotunplug event makes a cpuset empty (w/o any cpu or
    > >> memory).
    > >>
    > >> This patchset decouples cpuset locking from cgroup_mutex. After the
    > >> patchset, cpuset uses cpuset-specific cpuset_mutex instead of
    > >> cgroup_mutex. This also removes the lockdep warning triggered during
    > >> cpu offlining (see 0009).
    > >>
    > >> Note that this leaves memcg as the only external user of cgroup_mutex.
    > >> Michal, Kame, can you guys please convert memcg to use its own locking
    > >> too?
    > >>
    > >
    > > Hmm. let me see....at quick glance cgroup_lock() is used at
    > > hierarchy policy change
    > > kmem_limit
    > > migration policy change
    > > swapiness change
    > > oom control
    > >
    > > Because all aboves takes care of changes in hierarchy,
    > > Having a new memcg's mutex in ->create() may be a way.
    > >
    > > Ah, hm, Costa is mentioning task-attach. is the task-attach problem in memcg ?
    > >
    >
    > We disallow the kmem limit to be set if a task already exists in the
    > cgroup. So we can't allow a new task to attach if we are setting the limit.

    This is racy without additional locking, isn't it?

    --
    Michal Hocko
    SUSE Labs


    \
     
     \ /
      Last update: 2012-11-30 11:01    [W:4.181 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site