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

["'David Gibson'" <david@gibson.dropbear.id.au>]

On Thu, Apr 15, 2004 at 10:08:22AM -0700, Chen, Kenneth W wrote:
> >>>> 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.

The hugepte entries go in the same slots as pmd entries, which means
they must be compatible with the layout of pmd entries.  That's not
compatible with making them identical to normal PTE entries.  For one
thing, normal PTE entries are 64 bits wide, whereas PMD entries are
only 32 bits wide.

-- 
David Gibson			| For every complex problem there is a
david AT gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.
http://www.ozlabs.org/people/dgibson