From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with SMTP id DAC436B0062 for ; Fri, 18 Dec 2009 11:05:16 -0500 (EST) Date: Fri, 18 Dec 2009 17:04:37 +0100 From: Andrea Arcangeli Subject: Re: [PATCH 28 of 28] memcg huge memory Message-ID: <20091218160437.GP29790@random.random> References: <20091218103312.2f61bbfc.kamezawa.hiroyu@jp.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091218103312.2f61bbfc.kamezawa.hiroyu@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org To: KAMEZAWA Hiroyuki 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 , Christoph Lameter , Chris Wright , Andrew Morton List-ID: On Fri, Dec 18, 2009 at 10:33:12AM +0900, KAMEZAWA Hiroyuki wrote: > Then, maybe we (I?) should cut this part (and some from 27/28) out and > merge into memcg. It will be helpful to all your work. You can't merge this part, huge_memory.c is not there yet. But you should merge 27/28 instead, that one is self contained. > But I don't like a situation which memcg's charge are filled with _locked_ memory. There's no locked memory here. It's all swappable. > (Especially, bad-configured softlimit+hugepage will adds much regression.) > New counter as "usage of huge page" will be required for memcg, at least. no, hugepages are fully transparent and userland can't possibly know if it's running on hugepages or regular pages. The only difference is in userland going faster, everything else is identical so there's no need of any other memcg. -- 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