From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: patch: qemu + hugetlbfs..
Date: Tue, 08 Jul 2008 20:08:22 -0500
Message-ID: <48740F86.3050306@codemonkey.ws>
References: <4873E400.4000409@third-harmonic.com> <4873F395.6030209@codemonkey.ws> <4874051A.8000802@third-harmonic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: kvm@vger.kernel.org, mtosatti@redhat.com, john.cooper@redhat.com
To: john cooper <john.cooper@third-harmonic.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from wr-out-0506.google.com ([64.233.184.233]:13826 "EHLO
	wr-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751297AbYGIBIs (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 8 Jul 2008 21:08:48 -0400
Received: by wr-out-0506.google.com with SMTP id 69so2002334wri.5
        for <kvm@vger.kernel.org>; Tue, 08 Jul 2008 18:08:47 -0700 (PDT)
In-Reply-To: <4874051A.8000802@third-harmonic.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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