Re: patch: qemu + hugetlbfs..

[Anthony Liguori <anthony@codemonkey.ws>]

john cooper wrote:
> Anthony Liguori wrote:
>> john cooper wrote:
>>> 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.
>
> Well, yes it will round the allocation.  But from a
> minimally sufficient 4KB boundary to that of 4MB/2MB
> relative to a 32/64 bit x86 host which is excessive.
>
>>> 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.
>
> I don't see any harm reverting the name.  But I do
> believe it is largely cosmetic as given the above,
> the current code does require some work to make it
> independent of huge page assumptions.  Update attached.
>
> -john

Looks good to me.

Acked-by: Anthony Liguori <aliguori@us.ibm.com>