Re: patch: qemu + hugetlbfs..

[Anthony Liguori <anthony@codemonkey.ws>]

john cooper wrote:
> Anthony Liguori wrote:
>
>>> +#include <asm/param.h>
>>>   
>>
>> I don't think this is necessary anymore.  Depending on a Linux 
>> headers breaks the QEMU build on other unices so it's a bad thing.
>
> It is no longer required, but see below.
>
>> hpage is a misnomer too as we aren't actually dependent on huge pages 
>> (this code should work equally well for tmpfs).
>
> As it currently exists alloc_hpage_mem() is tied to
> the notion of huge page allocation as it will reference
> gethugepagesize() irrespective of *mem_path.  So even
> in the case of tmpfs backed files, if the host kernel
> has been configured with CONFIG_HUGETLBFS we will wind
> up doing allocations of /dev/shm mapped files at
> /proc/meminfo:Hugepagesize granularity.

Which is fine.  It just means we round -m values up to even numbers.

>   Otherwise if
> HUGETLBFS is not configured gethugepagesize() returns
> zero and alloc_hpage_mem() itself will not perform the
> allocation.

That sounds like a bug.

>
> Probably not what was intended but probably not too
> much of a concern as "-mem-path /dev/shm" is likely
> only used in debug of this flag and associated logic.
> I don't see it currently being worth the trouble to
> correct from a squeaky clean POV, and doing so may
> drag in far more than the header file we've just
> booted above to deal with this architecture/config
> dependency.

Renaming a function to a name that's less accurate seems bad to me.  I 
don't mean to be pedantic, but it seems like a strange thing to do.  I 
prefer it the way it was before.

Regards,

Anthony Liguori

> An updated patch is attached.
>
> -john
>