From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with SMTP id 0CCFD620002 for ; Thu, 24 Dec 2009 06:41:23 -0500 (EST) Date: Thu, 24 Dec 2009 12:40:25 +0100 From: Andrea Arcangeli Subject: Re: [PATCH 28 of 28] memcg huge memory Message-ID: <20091224114025.GK6429@random.random> References: <20091224100030.GD13983@balbir.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091224100030.GD13983@balbir.in.ibm.com> Sender: owner-linux-mm@kvack.org To: Balbir Singh Cc: linux-mm@kvack.org, Marcelo Tosatti , Adam Litke , Avi Kivity , Izik Eidus , Hugh Dickins , Nick Piggin , Rik van Riel , Mel Gorman , Andi Kleen , Dave Hansen , Benjamin Herrenschmidt , Ingo Molnar , Mike Travis , KAMEZAWA Hiroyuki , Christoph Lameter , Chris Wright , Andrew Morton List-ID: On Thu, Dec 24, 2009 at 03:30:30PM +0530, Balbir Singh wrote: > Charging huge pages might be OK, but I wonder if we should create a > separate counter since hugepages are not reclaimable. I am yet to > look at the complete series, does this series make hugepages > reclaimable? Could you please update Documentation/cgroups/memcg* as > well. The transparent hugepage that you quoted are reclaimable (actually swappable/pageable, reclaimable isn't exact term for them), but the point is that you can't see the different from userland so they can't deserve a special counter. The hugetlbfs pages (not in patch above) are still not swappable but they're not relevant with this patchset. The whole point of transparent hugepage is that the user shouldn't even notice they exist and it'll be the kernel to decide if it worth using them or not, and when to split them if needed. Apps however would better use madvise(MADV_HUGEPAGE) on large chunks of malloc memory that will benefit from hugepages, because certain users like embedded may want to turn off hugepages in all areas except the ones marked by madvise. Transparent Hugepages may or may not generate some minor memory and CPU waste depending on usage, so for memory constrained devices it worth enabling them only where they generate zero memory loss and zero CPU loss (even the prelloacted pte that is required to guarantee success of split_huge_page would have been allocated anyway if hugepages were disabled). -- 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