Re: [patch 06/18] hugetlb: multi hstate proc files

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

On 23.04.2008 [11:53:08 +1000], npiggin@suse.de wrote:
> Convert /proc output code over to report multiple hstates
> 
> I chose to just report the numbers in a row, in the hope 
> to minimze breakage of existing software. The "compat" page size
> is always the first number.

Only if add_huge_hstate() is called first for the compat page size,
right? That seems bad if we depend on an ordering.

For instance, for power, I think Jon is calling huge_add_hstate() from
the arch/powerpc/mm/hugetlbpage.c init routine. Which runs before
hugetlb_init, which means that if he adds hugepages like

huge_add_hstate(64k-order);
huge_add_hstate(16m-order);
huge_add_hstate(16g-order);

We'll get 64k as the first field in meminfo.

So perhaps what we should do is:

1) architectures define HPAGE_* as the default (compat) hugepage values
2) architectures have a call into generic code at their init time to
specify what sizes they support
3) the core is the only place that actually does huge_add_hstate() and
it always does it first for the compat order?

I wonder if this might lead to issues in timing between processing
hugepagesz= (in arch code) and hugepages= (in generic code). Not sure. I
guess if we always add all hugepage sizes, we should have all the
hstates we know about ready to configure and as long as hugetlb_init
runs before hugepages= processing, we should be fine? Dunno.

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center

--
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>