Re: patch: qemu + hugetlbfs..

[Anthony Liguori <anthony@codemonkey.ws>]

john cooper wrote:
> I like it even less.  MAP_POPULATE does not fault in physical
> hpages to the map.  Again this was a qemu-side interim bandaid.

Really?  That would seem like a bug in hugetlbfs to me.

>>> +/* we failed to fault in hpage *a, fall back to conventional page 
>>> mapping
>>> + */
>>> +int remap_hpage(void *a, int sz)
>>> +{
>>> +    ASSERT(!(sz & (EXEC_PAGESIZE - 1)));
>>> +    if (munmap(a, sz) < 0)
>>> +    perror("remap_hpage: munmap");
>>> +    else if (mmap(a, sz, PROT_READ|PROT_WRITE,
>>> +    MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, -1, 0) == MAP_FAILED)
>>> +        perror("remap_hpage: mmap");
>>> +    else
>>> +    return (1);
>>> +    return (0);
>>> +}
>>>   
>>
>> I think this would be simplified with MAP_POPULATE since you can fail 
>> in large chunks of memory instead of potentially having a highly 
>> fragmented set of VMAs.
>
> Here for 4K pages we only need to setup the map.  If we later
> fault on a physically absent 4K page we'll wait if a page isn't
> immediately available.  Rather in the case of a hpage being
> unavailable, we'll terminate.  Note at this point we've effectively
> locked onto whatever hpages we've been able to map as they can't
> be reclaimed from us until we exit.

Right now.  Once we drop references to the large pages, there's nothing 
preventing them from being reclaimed in the future.  That's what I'm 
concerned about.

Regards,

Anthony Liguori