Hello,
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.
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
In 4k mode, we could use 512k HUGE PAGE and have a HPAGE offset of 19
bits so HPTE offset of 3 bits and PGD offset of 10 bits
In 16k mode, we could use both 512k HUGE PAGE and 8M HUGE PAGE and have:
* For 512k: a HPAGE offset of 19 bits so HPTE offset of 7 bits and PGD
offset of 6 bits
* For 8M: a HPAGE offset of 23 bits so HPTE offset of 3 bits and PGD
offset of 6 bits
In see in the current ppc kernel that for PPC32, SYS_SUPPORTS_HUGETLBFS
is selected only if we have PHYS_64BIT.
What is the reason for only implementing HUGETLBFS with 64 bits phys
addresses ?
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 ?
Christophe
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
On Wed, 2016-06-08 at 09:03 +0200, Christophe Leroy wrote:
In see in the current ppc kernel that for PPC32, SYS_SUPPORTS_HUGETLBFS
is selected only if we have PHYS_64BIT.
What is the reason for only implementing HUGETLBFS with 64 bits phys
addresses ?
That's not for PPC32 in general -- it's for 32-bit FSL Book E. The reason for
the limitation is that there are separate TLB miss handlers depending on
whether PHYS_64BIT is enabled, and we didn't want to have to implement hugetlb
support in both of them unless there was actual demand for it.
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 ?
Yes.
-Scott