Re: [patch 17/18] x86: add hugepagesz option on 64-bit

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

On 30.04.2008 [22:19:32 +0200], Andi Kleen wrote:
> > Then let's just merge whatever we'd like all the time? Why have review
> > at all?
> 
> Looking for bugs and problems is good, but to be honest many of your
> comments like more like "nit picking until it looks exactly what I
> would have written" and that is not the purpose of a review.

I'm sorry if that is how it appears. I promise you that is not the case.
You and Nick have tackled a hard problem and come up with an overall
good solution to it. I believe I said something similar in my reply to
the core (first) patch which abstracts the hstate in the first place. I
admittedly have not heard from Nick on any of my comments, so perhaps he
shares the same view that they are not productive. If so, I'll hold off
on any further review.

> > To quote Nick from a separate discussion on similar future-proofing:
> > 
> > "Let's really try to put some thought into new sysfs locations. Not just
> > will it work, but is it logical and will it work tomorrow..."
> 
> ABIs are different from code, they have to be more future proof
> because changing them has more impact (although that seems to be
> commonly ignored in sysfs)
> 
> > infrastructure we have in place, where it claims to be generic and
> 
> The hugetlbfs code actually doesn't claim that.

The hugetlb.c code is architecture independent and roughly generic (it
doesn't know a whole lot about the underlying architecture itself).
hstates are defined and used in this independent code -- hence my
perspective that we want to make sure it is flexible enough to handle
other architectures than x86_64, or at least easily extensible to them.

> > usable by architectures (as has been my impression from the discussions
> > so far -- that it is extensible to other architectures), I want to be
> > sure that is really the case.
> 
> It is with some future changes, but there is no need to do them for
> the initial merge, but they can be done as additional architectures
> are added.

Well, Nick was talking about adding the powerpc bits to his stack when
he submited for -mm, so these discussions should be happening now,
AFAICT.

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>