Messages in this thread | | | Date | Wed, 22 Feb 2012 07:43:20 +0400 | From | Konstantin Khlebnikov <> | Subject | Re: [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
| |