Re: [patch 00/18] multi size, and giant hugetlb page support, 1GB hugetlb for x86

[Nishanth Aravamudan <nacc@us.ibm.com>]

On 23.04.2008 [10:05:45 +0200], Andi Kleen wrote:
> 
> > Testing-wise, I've changed the registration mechanism so that if you
> > specify hugepagesz=1G on the command line, then you do not get the
> > 2M pages by default (you have to also specify hugepagesz=2M). Also,
> > when only one hstate is registered, all the proc outputs appear
> > unchanged, so this makes it very easy to test with.
> 
> Are you sure that's a good idea? Just replacing the 2M count in
> meminfo with 1G pages is not fully compatible proc ABI wise I think.

If this is the case, then providing hugepagesz at all seems absurd on
x86_64?

That is, hugepagesz = 1G implies hugepagesz = 2M must also be specified?
If you're going to require that, then why not just have hugepages= with
a strict ordering? e.g., hugepages=10, is 10 2M pages; hugepages=10,2 is
10 2M pages and 2 1G pages. Well, I guess you're future-proofing against
adding another hugepage size in-between. If we're going to require this,
I hope the patchset has huge printk()s that functionality is being
disabled because the command-line was not spat out the right way.

And I'm not sure I buy the ABI argument? That implies that you can't
have differing hugepage sizes period, between boots, which we clearly
can on IA64, power, etc. Applications should be examining meminfo as is
for the underlying hugepagesize. Any app that hard-coded the size was
going to break eventually and was completely non-portable.

> I think rather that applications who only know about 2M pages should
> see "0" in this case and not be confused by larger pages. And only
> applications who are multi page size aware should see the new page
> sizes.

Applications could be using libhugetlbfs and not need to know about the
pages in particular (we also export a gethugepagesize() call, which will
need adjustment for multiple fields in /proc/meminfo -- something like
gethugepagesizes(), I guess, where gethugepagesize() returns the default
hugepages size, which should always be the first listed in
/proc/meminfo).

> If you prefer it you could move all the new page sizes to sysfs
> and only ever display the "legacy page size" in meminfo,
> but frankly I personally prefer the quite simple and comparatively
> efficient /proc/meminfo with multiple numbers interface.

Well, some things should be moved to sysfs, I'd say. I'm working on it
as we speak.

Thanks,
Nish

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>