lkml.org 
[lkml]   [2010]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] memcg: update documentation v5
    On Tue, Apr 13, 2010 at 08:38:43PM +0530, Balbir Singh wrote:
    > * Vivek Goyal <vgoyal@redhat.com> [2010-04-13 10:03:02]:
    >
    > > On Tue, Apr 13, 2010 at 09:57:18AM -0400, Vivek Goyal wrote:
    > > > On Tue, Apr 13, 2010 at 01:45:53PM +0900, KAMEZAWA Hiroyuki wrote:
    > > >
    > >
    > > Typed wrong email id last time and mail bounced. So here is another
    > > attempt.
    > >
    > > > [..]
    > > > > -2. Locking
    > > > > +2.6 Locking
    > > > >
    > > > > -The memory controller uses the following hierarchy
    > > > > + lock_page_cgroup()/unlock_page_cgroup() should not be called under
    > > > > + mapping->tree_lock.
    > > > >
    > > >
    > > > Because I never understood very well, I will ask. Why lock_page_cgroup()
    > > > should not be called under mapping->tree_lock?
    > > >
    >
    > The closest reference I can find to a conversation regarding this is
    >
    > http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-05/msg05158.html
    >

    Thanks Balbir. So basically idea is that page_cgroup_lock() does not
    disable interrupts hence can be interrupted. So don't do
    lock_page_cgroup() in interrupt context at all otherwise it can lead to
    various kind of deadlock scenarios.

    One of those scenarios is lock_page_cgroup() under mapping->tree_lock.

    That helps. Thanks

    Vivek

    > --
    > Three Cheers,
    > Balbir


    \
     
     \ /
      Last update: 2010-04-13 17:19    [W:6.571 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site