[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080528155809.9CD0.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Date: Wed, 28 May 2008 20:04:38 +0900
From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc: kosaki.motohiro@...fujitsu.com,
Lee Schermerhorn <Lee.Schermerhorn@...com>,
Rik van Riel <riel@...hat.com>, balbir@...ux.vnet.ibm.com,
linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>
Subject: [RFC PATCH] No Reclaim LRU Infrastructure enhancement for memcgroup
Hi
> In my understanding, 2 checks we have to do.
>
> 1. When memcg finds PG_noreclaim page in its LRU, move it to noreclaim list of
> memcg.
> 2. When PG_noreclaim page is moved back to generic LRU, memcg should move
> it on its list. (we have to add a hook somewhere.)
>
> But this may break current 'loose' synchronization between global LRU and
> memcg's LRU. When PG_noreclaim page is put back into active/inactive LRU ?
>
> concerns are
> A. how to implement '2'
I tried to implement it today.
this patch is made against "[PATCH -mm 13/16] No Reclaim LRU Infrastructure"
> B. race condtions.
don't worry :)
it isn't big problem.
global lru is reclaimbale and memcg lru is noreclaimable
-> we can repair at move lru of shrink_[in]active_page().
global lru is noreclaimbale and memcg lru is reclaimable
-> we can repair mem_cgroup_isolate_pages()
Download attachment "rvr-13.2-kosaki-memcg-noreclaim.patch" of type "application/octet-stream" (7316 bytes)
Download attachment "rvr-13.3-kosaki-memcg-stat.patch" of type "application/octet-stream" (1165 bytes)
Powered by blists - more mailing lists