From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.suse.de (ns.suse.de [195.135.220.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mx1.suse.de", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTP id 2D04867B74 for ; Wed, 30 Aug 2006 17:20:04 +1000 (EST) From: Andi Kleen To: Nishanth Aravamudan Subject: Re: libnuma interleaving oddness Date: Wed, 30 Aug 2006 09:19:13 +0200 References: <20060829231545.GY5195@us.ibm.com> <20060830002110.GZ5195@us.ibm.com> In-Reply-To: <20060830002110.GZ5195@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-Id: <200608300919.13125.ak@suse.de> Cc: linuxppc-dev@ozlabs.org, linux-mm@kvack.org, lnxninja@us.ibm.com, Christoph Lameter List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , mous pages. > > The order is (with necessary params filled in): > > p = mmap( , newsize, RW, PRIVATE, unlinked_hugetlbfs_heap_fd, ); > > numa_interleave_memory(p, newsize); > > mlock(p, newsize); /* causes all the hugepages to be faulted in */ > > munlock(p,newsize); > > From what I gathered from the numa manpages, the interleave policy > should take effect on the mlock, as that is "fault-time" in this > context. We're forcing the fault, that is. mlock shouldn't be needed at all here. the new hugetlbfs is supposed to reserve at mmap time and numa_interleave_memory() sets a VMA policy which will should do the right thing no matter when the fault occurs. Hmm, maybe mlock() policy() is broken. -Andi From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: libnuma interleaving oddness Date: Wed, 30 Aug 2006 09:19:13 +0200 References: <20060829231545.GY5195@us.ibm.com> <20060830002110.GZ5195@us.ibm.com> In-Reply-To: <20060830002110.GZ5195@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608300919.13125.ak@suse.de> Sender: owner-linux-mm@kvack.org Return-Path: To: Nishanth Aravamudan Cc: Christoph Lameter , linux-mm@kvack.org, linuxppc-dev@ozlabs.org, lnxninja@us.ibm.com, agl@us.ibm.com List-ID: mous pages. > > The order is (with necessary params filled in): > > p = mmap( , newsize, RW, PRIVATE, unlinked_hugetlbfs_heap_fd, ); > > numa_interleave_memory(p, newsize); > > mlock(p, newsize); /* causes all the hugepages to be faulted in */ > > munlock(p,newsize); > > From what I gathered from the numa manpages, the interleave policy > should take effect on the mlock, as that is "fault-time" in this > context. We're forcing the fault, that is. mlock shouldn't be needed at all here. the new hugetlbfs is supposed to reserve at mmap time and numa_interleave_memory() sets a VMA policy which will should do the right thing no matter when the fault occurs. Hmm, maybe mlock() policy() is broken. -Andi -- 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