Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756080AbYHUDi1 (ORCPT ); Wed, 20 Aug 2008 23:38:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753279AbYHUDiR (ORCPT ); Wed, 20 Aug 2008 23:38:17 -0400 Received: from E23SMTP05.au.ibm.com ([202.81.18.174]:40625 "EHLO e23smtp05.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754507AbYHUDiQ (ORCPT ); Wed, 20 Aug 2008 23:38:16 -0400 Message-ID: <48ACE2D5.8090106@linux.vnet.ibm.com> Date: Thu, 21 Aug 2008 09:06:53 +0530 From: Balbir Singh Reply-To: balbir@linux.vnet.ibm.com Organization: IBM User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: KAMEZAWA Hiroyuki CC: LKML , "yamamoto@valinux.co.jp" , "nishimura@mxp.nes.nec.co.jp" , ryov@valinux.co.jp, "linux-mm@kvack.org" Subject: Re: [RFC][PATCH -mm 0/7] memcg: lockless page_cgroup v1 References: <20080819173014.17358c17.kamezawa.hiroyu@jp.fujitsu.com> <20080820185306.e897c512.kamezawa.hiroyu@jp.fujitsu.com> <20080820194108.e76b20b3.kamezawa.hiroyu@jp.fujitsu.com> <20080820200006.a152c14c.kamezawa.hiroyu@jp.fujitsu.com> <20080821111740.49f99038.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: <20080821111740.49f99038.kamezawa.hiroyu@jp.fujitsu.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2915 Lines: 71 KAMEZAWA Hiroyuki wrote: > On Wed, 20 Aug 2008 20:00:06 +0900 > KAMEZAWA Hiroyuki wrote: > >> On Wed, 20 Aug 2008 19:41:08 +0900 >> KAMEZAWA Hiroyuki wrote: >> >>> On Wed, 20 Aug 2008 18:53:06 +0900 >>> KAMEZAWA Hiroyuki wrote: >>> >>>> Hi, this is a patch set for lockless page_cgroup. >>>> >>>> dropped patches related to mem+swap controller for easy review. >>>> (I'm rewriting it, too.) >>>> >>>> Changes from current -mm is. >>>> - page_cgroup->flags operations is set to be atomic. >>>> - lock_page_cgroup() is removed. >>>> - page->page_cgroup is changed from unsigned long to struct page_cgroup* >>>> - page_cgroup is freed by RCU. >>>> - For avoiding race, charge/uncharge against mm/memory.c::insert_page() is >>>> omitted. This is ususally used for mapping device's page. (I think...) >>>> >>>> In my quick test, perfomance is improved a little. But the benefit of this >>>> patch is to allow access page_cgroup without lock. I think this is good >>>> for Yamamoto's Dirty page tracking for memcg. >>>> For I/O tracking people, I added a header file for allowing access to >>>> page_cgroup from out of memcontrol.c >>>> >>>> The base kernel is recent mmtom. Any comments are welcome. >>>> This is still under test. I have to do long-run test before removing "RFC". >>>> >>> Known problem: force_emtpy is broken...so rmdir will struck into nightmare. >>> It's because of patch 2/7. >>> will be fixed in the next version. >>> >> This is a quick fix but I think I can find some better solution.. >> == >> Because removal from LRU is delayed, mz->lru will never be empty until >> someone kick drain. This patch rotate LRU while force_empty and makes >> page_cgroup will be freed. >> > > I'd like to rewrite force_empty to move all usage to "default" cgroup. > There are some reasons. > > 1. current force_empty creates an alive page which has no page_cgroup. > This is bad for routine which want to access page_cgroup from page. > And this behavior will be an issue of race condition in future. > 2. We can see amount of out-of-control usage in default cgroup. > > But to do this, I'll have to avoid "hitting limit" in default cgroup. > I'm now wondering to make it impossible to set limit to default cgroup. > (will show as a patch in the next version of series.) > Does anyone have an idea ? > Hi, Kamezawa-San, The definition of default-cgroup would be root cgroup right? I would like to implement hierarchies correctly in order to define the default-cgroup (it could be a parent of the child cgroup for example). -- Balbir -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/