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.le...@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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
