Date: Wed, 10 May 2006 21:49:28 +0100
From: Christoph Hellwig <hch@infradead.org>
To: Adam Litke <agl@us.ibm.com>
Cc: Christoph Hellwig <hch@infradead.org>, linux-mm@kvack.kernel.org,
       linux-kernel@vger.kernel.org
Subject: Re: [RFC] Hugetlb demotion for x86
Message-ID: <20060510204928.GA31315@infradead.org>
Mail-Followup-To: Christoph Hellwig <hch@infradead.org>,
	Adam Litke <agl@us.ibm.com>, linux-mm@kvack.kernel.org,
	linux-kernel@vger.kernel.org
References: <1147287400.24029.81.camel@localhost.localdomain> <20060510200516.GA30346@infradead.org> <1147293156.24029.95.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1147293156.24029.95.camel@localhost.localdomain>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 975
Lines: 18

On Wed, May 10, 2006 at 03:32:36PM -0500, Adam Litke wrote:
> By smart fallback do you mean we should convert the hugetlb fault code
> back to using VM_FAULT_SIGBUS and writing userspace sighandlers to do
> the same thing I am, but in userspace?  FWIW I did implement that in
> libhugetlbfs to try it out, but that seems much dirtier to me than
> handling faults in the kernel.

Umm, why do these faults happen at all?  When all the hugetlb code went
in it we allocated at mmap time.  Later it was converted to demand faulting
but under the premise that we keep the strict overcommit accounting.  When
did that part go away aswell?  With strict overcommit handling for huge
pages no fault should happen when the pool is exausted.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/