From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lAC6uGar003806 for ; Mon, 12 Nov 2007 01:56:16 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.6) with ESMTP id lAC6uG8I449498 for ; Mon, 12 Nov 2007 01:56:16 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lAC6uFSM014821 for ; Mon, 12 Nov 2007 01:56:16 -0500 Message-ID: <4737F904.8080107@linux.vnet.ibm.com> Date: Mon, 12 Nov 2007 12:26:04 +0530 From: Balbir Singh Reply-To: balbir@linux.vnet.ibm.com MIME-Version: 1.0 Subject: Re: [PATCH 6/6 mm] memcgroup: revert swap_state mods References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Hugh Dickins Cc: Andrew Morton , KAMEZAWA Hiroyuki , linux-mm@kvack.org, containers@lists.osdl.org List-ID: Hugh Dickins wrote: > If we're charging rss and we're charging cache, it seems obvious that > we should be charging swapcache - as has been done. But in practice > that doesn't work out so well: both swapin readahead and swapoff leave > the majority of pages charged to the wrong cgroup (the cgroup that > happened to read them in, rather than the cgroup to which they belong). > > (Which is why unuse_pte's GFP_KERNEL while holding pte lock never > showed up as a problem: no allocation was ever done there, every page > read being already charged to the cgroup which initiated the swapoff.) > > It all works rather better if we leave the charging to do_swap_page and > unuse_pte, and do nothing for swapcache itself: revert mm/swap_state.c > to what it was before the memory-controller patches. This also speeds > up significantly a contained process working at its limit: because it > no longer needs to keep waiting for swap writeback to complete. > Yes, it does speed up things, but we lose control over swap cache. It might grow very large, but having said that I am in favour of removing the mods till someone faces a severe problem with them. Another approach is to provide a per-container tunable as to whether swap cache should be controlled or not and document the side-effects of swap cache control. > Is it unfair that swap pages become uncharged once they're unmapped, > even though they're still clearly private to particular cgroups? For > a short while, yes; but PageReclaim arranges for those pages to go to > the end of the inactive list and be reclaimed soon if necessary. > > shmem/tmpfs pages are a distinct case: their charging also benefits > from this change, but their second life on the lists as swapcache > pages may prove more unfair - that I need to check next. > > Signed-off-by: Hugh Dickins Thanks for the patch Acked-by: Balbir Singh -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL -- 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