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

[Andy Whitcroft <apw@shadowen.org>]

--On 31 March 2004 00:51 -0800 "Chen, Kenneth W" <kenneth.w.chen@intel.com>
wrote:

>>>>> Andy Whitcroft wrote on Tuesday, March 30, 2004 5:49 PM
>>>> 	fd = open("/mnt/htlb/myhtlbfile", O_CREAT|O_RDWR, 0755);
>>>> 	mmap(..., fd, offset);
>>>> 
>>>> Accounting didn't happen in this case, (grep Huge /proc/meminfo):
>> 
>> O.k.  Try this one.  Should fix that case.  There is some uglyness in
>> there which needs review, but my testing says this works.
> 
> Under common case, worked perfectly!  But there are always corner cases.
> 
> I can think of two ugliness:
> 1. very sparse hugetlb file.  I can mmap one hugetlb page, at offset
>    512 GB.  This would account 512GB + 1 hugetlb page as committed_AS.
>    But I only asked for one page mapping.  One can say it's a feature,
>    but I think it's a bug.

Yes.  This is true.  This is consistent with the preallocation behaviour of
shared memory segments, but inconsistent with the behaviour of mmap'ing
/dev/zero which it essentially emulates.  This is not trival to fix as we
do not get informed when the unmap occurs.  Accounting for normal pages is
handled directly by the VM unmap code.  I think I have found a way to track
these but it does blur the interfaces between the hugetlbfs and hugepage
implementations.

There are a number of other 'bugs' in the implementation of hugetlb.  For
example, the MAP_SHARED/MAP_PRIVATE flags are ignored, behaviour is
identical in both cases.

> 2. There is no error checking (to undo the committed_AS accounting) after
>    hugetlb_prefault(). hugetlb_prefault doesn't always succeed in allocat-
>    ing all the pages user asked for due to disk quota limit.  It can have
>    partial allocation which would put the committed_AS in a wedged state.

True, this needs work on the interface to the quota system in hugetlbfs.
We essentially need to check the quota before we attempt to fault any
pages.  I'll change it around see how it looks.

Expect new patches tomorrow ...

-apw