* [RFC] Implementing HUGEPAGE on MPC 8xx
@ 2016-06-08 7:03 Christophe Leroy
2016-06-08 22:46 ` Dan Malek
2016-06-09 0:15 ` Scott Wood
0 siblings, 2 replies; 3+ messages in thread
From: Christophe Leroy @ 2016-06-08 7:03 UTC (permalink / raw)
To: LinuxPPC-dev, Becky Bruce, David Gibson, Benjamin Herrenschmidt,
Scott Wood
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] Implementing HUGEPAGE on MPC 8xx
2016-06-08 7:03 [RFC] Implementing HUGEPAGE on MPC 8xx Christophe Leroy
@ 2016-06-08 22:46 ` Dan Malek
2016-06-09 0:15 ` Scott Wood
1 sibling, 0 replies; 3+ messages in thread
From: Dan Malek @ 2016-06-08 22:46 UTC (permalink / raw)
To: Christophe Leroy
Cc: LinuxPPC-dev, Becky Bruce, David Gibson, Benjamin Herrenschmidt,
Scott Wood
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 <christophe.leroy@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.
>=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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFC] Implementing HUGEPAGE on MPC 8xx
2016-06-08 7:03 [RFC] Implementing HUGEPAGE on MPC 8xx Christophe Leroy
2016-06-08 22:46 ` Dan Malek
@ 2016-06-09 0:15 ` Scott Wood
1 sibling, 0 replies; 3+ messages in thread
From: Scott Wood @ 2016-06-09 0:15 UTC (permalink / raw)
To: Christophe Leroy, LinuxPPC-dev, Becky Bruce, David Gibson,
Benjamin Herrenschmidt
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-06-09 0:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-08 7:03 [RFC] Implementing HUGEPAGE on MPC 8xx Christophe Leroy
2016-06-08 22:46 ` Dan Malek
2016-06-09 0:15 ` Scott Wood
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.