From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932936AbYEFUhy (ORCPT ); Tue, 6 May 2008 16:37:54 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756561AbYEFUhn (ORCPT ); Tue, 6 May 2008 16:37:43 -0400 Received: from extu-mxob-1.symantec.com ([216.10.194.28]:50332 "EHLO extu-mxob-1.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757384AbYEFUhl (ORCPT ); Tue, 6 May 2008 16:37:41 -0400 Date: Tue, 6 May 2008 21:36:59 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@blonde.site To: Hans Rosenfeld cc: Ingo Molnar , Jeff Chua , Thomas Gleixner , "H. Peter Anvin" , Gabriel C , Arjan van de Ven , Nishanth Aravamudan , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] x86: fix PAE pmd_bad bootup warning In-Reply-To: <20080506202201.GB12654@escobedo.amd.com> Message-ID: References: <20080506124946.GA2146@elte.hu> <20080506202201.GB12654@escobedo.amd.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 6 May 2008, Hans Rosenfeld wrote: > On Tue, May 06, 2008 at 08:49:23PM +0100, Hugh Dickins wrote: > > So Hans' original hugepage leak remains unexplained and unfixed. > > Hans, did you find that hugepage leak with a standard kernel, or were > > you perhaps trying out some hugepage-using patch of your own, without > > marking the vma VM_HUGETLB? Or were you expecting the hugetlbfs file > > to truncate itself once all mmappers had gone? If the standard kernel > > leaks hugepages, I'm surprised the hugetlb guys don't know about it. > > I used a standard kernel (well, not quite, I had made some changes to > the /proc/pid/pagemap code, but nothing that would affect the hugepage > stuff) and some simple test program that would just mmap a hugepage. > > I expected that any hugepage that a process had mmapped would > automatically be returned to the system when the process exits. That was > not the case, the process exited and the hugepage was lost (unless I > changed the program to explicitly munmap the hugepage before exiting). > Removing the hugetlbfs file containing the hugepage also didn't free the > page. Hmm. That doesn't fit with my experience: I've not found an explicit munmap makes any difference (I wouldn't expect it to), but removing the file once all openers gone does free everything up. I guess I'm overlooking something more experienced hugepagers will soon light upon. Hugh