Re: [RFC] Implementing HUGEPAGE on MPC 8xx

Hello Christophe.

I=E2=80=99m surprised there is still any interest in this processor =
family :)

On Jun 8, 2016, at 12:03 AM, Christophe Leroy [off-list ref] =
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.

=20
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=E2=80=99t 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=E2=80=99t =
know if 16k is a big enough win (unless it=E2=80=99s the =E2=80=9Cstandard=
=E2=80=9D page size to keep TLBmiss as simple as possible), or if 8M is =
terribly useful from user space.

=46rom 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.

	=E2=80=94 Dan