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

-- 
john.cooper@third-harmonic.com