RE: hugetlb demand paging patch part [0/3]

["Chen, Kenneth W" <kenneth.w.chen@intel.com>]

>>>> Chen, Kenneth W wrote on Thursday, April 15, 2004 10:08 AM
> >>>> David Gibson wrote on Wednesday, April 14, 2004 11:43 PM
> > >
> > > Some caveats:  I don't have sh and sparc64 hardware to test.  But hugetlb
> > > code in these two arch looked like a triplet twin of x86 code.  So I'm
> > > pretty sure it will work right out of box.  I've monkeyed around with
> > > ppc64 code and after a while I realized it should be left for the experts.
> > > I'm sure there are plenty ppc64 developers out there that can get it done
> > > in no time.
> >
> > To the extent that I understand your patches, it shouldn't be that
> > hard to adapt for ppc64, with one caveat: on ppc64, unlike the other
> > hugepage archs, the format of hugepage PTEs is not identical to the
> > format of normal PTEs.  So to do this for ppc64, the generic parts of
> > your code will need to use a hugepte_t instead of pte_t - it can be
> > typedeffed to pte_t on archs other than ppc64.  Likewise there will
> > need to be hugepte_none() and so forth macros.
>
> I think it would be cleaner if ppc64 change its format instead of changing
> 4 other arch to accommodate ppc64.  By the way, why do you need to special
> typedef hugepte_t? pte for huge page aren't anything special on all other
> arches.

Again, I'm not an expert on ppc64, but this look suspicious to me:

arch/ppc64/mm/hugetlbpage.c
/* HugePTE layout:
 *
 * 31 30 ... 15 14 13 12 10 9  8  7   6    5    4    3    2    1    0
 * PFN>>12..... -  -  -  -  -  -  HASH_IX....   2ND  HASH RW   -    HG=1
 */

#define HUGEPTE_SHIFT   15

17 bits for pfn?  It looks to me that huge page on ppc64 will break on
system with more than 2 Terabyte of physical memory.