Re: [PATCH] [0/6] HUGETLB memory commitment

From: Martin J. Bligh
Date: Sun Mar 28 2004 - 14:13:10 EST

> As I understood this originally, the suggestion was to reserve hugetlb
> pages at mmap() or shm_get() time so that the user would get an -ENOMEM
> at that time if there aren't enough hugetlb pages to (eventually) satisfy
> the request, as per the notion that we shouldn't modify the user API due
> to going with allocate on fault instead of hugetlb_prefault().

Yup, but there were two parts to it:

1. Stop hugepages using the existing overcommit pool for small pages,
which breaks small page allocations by prematurely the pool.
2. Give hugepages their own over-commit pool, instead of prefaulting.

Personally I think we need both (as you seem to), but (1) is probably
more urgent.

> Since the reservation belongs to the mapped object (file or segment),
> I've been storing the current file/segments's reservation in the file
> system dependent part of the inode. That way, it is easily accessible
> when the hugetlbfs file or SysV segment is removed and we can reduce
> the total number of reserved pages by that file's reservation at that
> time. This also allows us to handle the reservation in the absence
> of a vma, as per Andy'c comment below.

Do we need to store it there, or is one central pool number sufficient?
I would have thought it was ...

> Admittedly this doesn't alow one to request that hugetlbpages be
> overcommitted, or to handle problems caused to the "normal" page
> overcommit code due to the presence of hugepages. But we figure that
> anyone that is actually using hugetlb pages is likely to take over
> almost all of main memory anyway in a single job, so overcommit
> doesn't make much sense to us.

Seeing as you can't swap them, overcommitting makes no sense to me
either ;-)


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