Re: [PATCH 9/10] mm/memcg: move lru_lock into lruvec

[Konstantin Khlebnikov]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/