[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080805151956.A885.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Date: Tue, 05 Aug 2008 15:20:59 +0900
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: balbir@...ux.vnet.ibm.com
Cc: kosaki.motohiro@...fujitsu.com,
Lee Schermerhorn <Lee.Schermerhorn@...com>,
MinChan Kim <minchan.kim@...il.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
linux-mm <linux-mm@...ck.org>, Rik van Riel <riel@...hat.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Race condition between putback_lru_page and mem_cgroup_move_list
Hi Balbir-san,
> > I also think zone's lru lock is unnecessary.
> > So, I guess below "it" indicate lock_page_cgroup, not zone lru lock.
>
> We need zone LRU lock, since the reclaim paths hold them. Not sure if I
> understand why you call zone's LRU lock unnecessary, could you elaborate please?
I tought..
1. in general, one data structure should be protected by one lock.
2. memcgroup lru is protected by mem_cgroup_per_zone::lru_lock.
if zone LRU lock must be held, Why do mem_cgroup_per_zone::lru_lock exit?
it should be removed?
Could you explain detail of "race condition with global reclaim race" ?
> > I think both opinion is correct.
> > unevictable lru related code doesn't require pagevec.
> >
> > but mem_cgroup_move_lists is used by active/inactive list transition too.
> > then, pagevec is necessary for keeping reclaim throuput.
> >
>
> It's on my TODO list. I hope to get to it soon.
Very good news!
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists