[RFC] Implementing HUGEPAGE on MPC 8xx

Dan Malek d6malek at digitaldans.com
Thu Jun 9 08:46:15 AEST 2016


Hello Christophe.

I’m surprised there is still any interest in this processor family :)

On Jun 8, 2016, at 12:03 AM, Christophe Leroy <christophe.leroy at c-s.fr> wrote:

> MPC 8xx has several page sizes: 4k, 16k, 512k and 8M.
> Today, 4k and 16k sizes are implemented as normal page sizes and 8M is used for mapping linear memory space in kernel.
> 
> I'd like to implement HUGE PAGE to reduce TLB misses from user apps.

My original plan was to implement the TLB miss handler in three lines of code.  I haven’t investigated recently, but I know the amount of code has grown substantially :)

> In 4k mode, PAGE offset is 12 bits, PTE offset is 10 bits and PGD offset is 10 bits
> In 16k mode, PAGE offset is 14 bits, PTE offset is 12 bits and PGD offset is 6 bits

Since the 8xx systems typically have rather small real memory, I was considering a combination of 4k and 512k pages as an attempt to maximize real memory utilization.  The 4k pages in the PTE tables as today, and the 512k flagged in the PGD and just loaded from there.  I don’t know if 16k is a big enough win (unless it’s the “standard” page size to keep TLBmiss as simple as possible), or if 8M is terribly useful from user space.

> From your point of view, what would be the best approach to extend support of HUGE PAGES to PPC_8xx ?
> Would the good starting point be to implement a hugepagetlb-8xx.c from hugepagetlb-book3e.c ?

I guess that is the place to start.  When I first thought about this many years ago, I was hoping to map shared libraries and properly behaving programs.  The mechanism I considered to do this was either inspection of the section headers, using some section flags, or maybe Aux Vector  to set up mmap() to hugetlb at run-time.

Good Luck.

	— Dan



More information about the Linuxppc-dev mailing list