[lkml]   [2012]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 9/10] mm/memcg: move lru_lock into lruvec
    Hugh Dickins wrote:
    > On Wed, 22 Feb 2012, Konstantin Khlebnikov wrote:
    >> Hugh Dickins wrote:
    >>> I'll have to come back to think about your locking later too;
    >>> or maybe that's exactly where I need to look, when investigating
    >>> the mm_inline.h:41 BUG.
    >> pages_count[] updates looks correct.
    >> This really may be bug in locking, and this VM_BUG_ON catch it before
    >> list-debug.
    > I've still not got into looking at it yet.
    > You're right to mention DEBUG_LIST: I have that on some of the machines,
    > and I would expect that to be the first to catch a mislocking issue.
    > In the past my problems with that BUG (well, the spur to introduce it)
    > came from hugepages.

    My patchset hasn't your mem_cgroup_reset_uncharged_to_root protection,
    or something to replace it. So, there exist race between cgroup remove and
    isolated uncharged page put-back, but it shouldn't corrupt lru lists.
    There something different.

    >>> But at first sight, I have to say I'm very suspicious: I've never found
    >>> PageLRU a good enough test for whether we need such a lock, because of
    >>> races with those pages on percpu lruvec about to be put on the lru.
    >>> But maybe once I look closer, I'll find that's handled by your changes
    >>> away from lruvec; though I'd have thought the same issue exists,
    >>> independent of whether the pending pages are in vector or list.
    >> Are you talking about my per-cpu page-lists for lru-adding?
    > Yes.
    >> This is just an unnecessary patch, I don't know why I include it into v2 set.
    >> It does not protect anything.
    > Okay.
    > Hugh

     \ /
      Last update: 2012-02-22 04:45    [W:0.027 / U:10.080 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site