[lkml]   [2004]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Hugepages demand paging V1 [3/4]: Overcommit handling
On Fri, Oct 22, 2004 at 12:01:16PM +0100, Christoph Hellwig wrote:
>>> overcommit for huge pages sounds like a realy bad idea. Care to explain
>>> why you want it?

On Fri, Oct 22, 2004 at 04:12:59AM -0700, William Lee Irwin III wrote:
> > It's the opposite of what its name implies; it implements strict
> > non-overcommit, in the sense that it tries to prevent the sum of
> > possible hugetlb allocations arising from handling hugetlb faults from
> > exceeding the size of the hugetlb memory pool.

On Fri, Oct 22, 2004 at 12:16:26PM +0100, Christoph Hellwig wrote:
> I thought that was the state of the art for hugetlb pages already?

Only vacuously so, for mainline is not handling hugetlb faults.

The real impediment to all this is that no one is bothering to dredge
up architecture manuals for the architectures they're touching to
create plausible equivalents of update_mmu_cache(), clear_dcache_page()
(not considered by Lameter's patches at all), et al for hugetlb.

-- wli
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.044 / U:0.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site