[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48982F9E.2080100@linux.vnet.ibm.com>
Date: Tue, 05 Aug 2008 16:16:54 +0530
From: Balbir Singh <balbir@...ux.vnet.ibm.com>
To: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
CC: 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
KOSAKI Motohiro wrote:
> 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.
In general yes, but in practice no. We have different paths through which a page
can be reclaimed. Consider the following
1. What happens if a global reclaim is in progress at the same time as memory
cgroup reclaim and they are both looking at the same page?
2. In the shared reclaim infrastructure, we move pages and update statistics for
pages belonging to a particular zone in a particular cgroup.
>> It's on my TODO list. I hope to get to it soon.
>
> Very good news!
I hope they show the benefit that I expect them too :)
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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