Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753394Ab0LQAGt (ORCPT ); Thu, 16 Dec 2010 19:06:49 -0500 Received: from fgwmail5.fujitsu.co.jp ([192.51.44.35]:39494 "EHLO fgwmail5.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751856Ab0LQAGs (ORCPT ); Thu, 16 Dec 2010 19:06:48 -0500 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Date: Fri, 17 Dec 2010 09:01:03 +0900 From: KAMEZAWA Hiroyuki To: Miklos Szeredi Cc: akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: add replace_page_cache_page() function Message-Id: <20101217090103.2a9ca19a.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: References: <20101216100744.e3a417cf.kamezawa.hiroyu@jp.fujitsu.com> Organization: FUJITSU Co. LTD. X-Mailer: Sylpheed 3.0.3 (GTK+ 2.10.14; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1499 Lines: 45 On Thu, 16 Dec 2010 13:05:44 +0100 Miklos Szeredi wrote: > On Thu, 16 Dec 2010, KAMEZAWA Hiroyuki wrote: > > Hmm, then, the page will be recharged to "current" instead of the memcg > > where "old" was under control. Is this design ? If so, why ? > > No, I just haven't thought about it. > > Porbably charging "new" to where "old" was charged is the logical > thing to do here. > > > > > In mm/migrate.c, following is called. > > > > charge = mem_cgroup_prepare_migration(page, newpage, &mem); > > ....do migration.... > > if (!charge) > > mem_cgroup_end_migration(mem, page, newpage); > > > > BTW, off topic, in fuse/dev.c > > > > add_to_page_cache_locked(page) > > This is the call which the above patch replaces with > replace_page_cache_page(). So if I fix replace_page_cache_page() to > charge "newpage" to the correct memory cgroup, that should solve all > problems, no? > No. memory cgroup expects all pages should be found on LRU. But, IIUC, pages on this radix-tree will not be on LRU. So, memory cgroup can't find it at destroying cgroup and can't reduce "usage" of resource to be 0. This makes rmdir() returns -EBUSY. I'm sorry if this page will be on LRU, somewhere. Thanks, -Kame -- 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/