From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m2.gw.fujitsu.co.jp ([10.0.50.72]) by fgwmail7.fujitsu.co.jp (Fujitsu Gateway) with ESMTP id mA58HDpj026343 for (envelope-from kamezawa.hiroyu@jp.fujitsu.com); Wed, 5 Nov 2008 17:17:13 +0900 Received: from smail (m2 [127.0.0.1]) by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 24A4A45DD7B for ; Wed, 5 Nov 2008 17:17:13 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92]) by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 00D8D45DD78 for ; Wed, 5 Nov 2008 17:17:13 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id D068C1DB8037 for ; Wed, 5 Nov 2008 17:17:12 +0900 (JST) Received: from ml13.s.css.fujitsu.com (ml13.s.css.fujitsu.com [10.249.87.103]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 774FB1DB803A for ; Wed, 5 Nov 2008 17:17:12 +0900 (JST) Date: Wed, 5 Nov 2008 17:16:37 +0900 From: KAMEZAWA Hiroyuki Subject: [RFC][PATCH 0/6] memcg updates (05/Nov) Message-Id: <20081105171637.1b393333.kamezawa.hiroyu@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: "linux-mm@kvack.org" Cc: "linux-kernel@vger.kernel.org" , "balbir@linux.vnet.ibm.com" , "menage@google.com" , "nishimura@mxp.nes.nec.co.jp" List-ID: Weekly (RFC) update for memcg. This set includes 1. change force_empty to do move account rather than forget all 2. swap cache handling 3. mem+swap controller kconfig 4. swap_cgroup for rememver swap account information 5. mem+swap controller core 6. synchronize memcg's LRU and global LRU. "1" is already sent, "6" is a newcomer. I'd like to push out "2" or "2-5" in the next week (if no bugs.) after 6, next candidates are - dirty_ratio handler - account move at task move. Some more explanation about purpose of "6". (see details in patch itself) Now, one of complicated logic in memcg is LRU handling. Because the place of lru_head depends on page_cgroup->mem_cgroup pointer, we have to take lock as following even under zone->lru_lock. == pc = lookup_page_cgroup(page); if (!trylock_page_cgroup(pc)) return -EBUSY; if (PageCgroupUsed(pc)) { struct mem_cgroup_per_zone *mz = page_cgroup_zoneinfo(pc); spin_lock_irqsave(&mz->lru_lock, flags); ....some operation on LRU. spin_unlock_irqrestore(&mz->lru_lock, flags); } unlock_page_cgroup(pc); == Sigh.. After "6", page_cgroup's LRU management can be done independently to some extent. == as (zone->lru_lock is held here) pc = lookup_page_cgroup(page); list operation on pc. (unlock zone->lru_lock) == Maybe good for maintainance and as a bonus, we can make use of isolate_lru_page() when doing some racy operation. isolate_lru_page(page); pc = lookup_page_cgroup(page); do some jobs. putback_lru_page(page); Maybe this will be a help to implement "account move at task move". Thanks, -Kame -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org