Re: Huge page support for PowerPC 32 bit and WIMG flexibility

[Kumar Gala <galak@kernel.crashing.org>]

On Jan 31, 2007, at 4:01 PM, Ilya Lipovsky wrote:

> Hi,
>
> I am not experienced in kernel development, so please be patient.
>
> After exploring the latest (2.19.2) sources it appears that there =20
> is no huge page support for the 32 bit powerpc platform. I deduced =20
> it by starting from 0x300 in head_32.S and comparing notes with =20
> head_64.S. It appears that the only sensible path for hashing in a =20
> huge page (on 64bit ppc) is via:
>
> 0x300: data_access -> do_hash_page -> hash_page -> hash_huge_page
>
> Unfortunately, on the 32bit, all paths that do anything useful end =20
> up in create_hpte() found in hash_low_32.S. I noticed someone on =20
> this mailing list claiming huge page support for IBM 44x core=85 Is =20=

> it possible to make it general enough to encompass ppc32 in general?
>
> Another issue I have is the absence of control over hardware =20
> specific attributes of memory such as WIMG. More concretely, I am =20
> interested in having the ability to allocate off the heap in such a =20=

> way so as to explicitly set the M (coherency) bit off =20
> (independently of SMP or non-SMP mode). This is needed because some =20=

> multicore PowerPC platforms (e.g. 745x) perform an extra address =20
> broadcast to guarantee cache coherency per each store miss on a =20
> cacheline. This degrades performance for store-bound programs.
>
> I understand that hashing pages as non-cache-coherent makes data =20
> contained therein a potential victim to cache coherency paradoxes. =20
> Nevertheless, since I am working on high performance library, I am =20
> prepared to shift coherency guarantees to the library, which is =20
> supposed the one managing the data flow between memory and CPU =20
> caches intelligently.
>
> So, I have 2 main questions:
>
> 1)       What=92s so special about ppc32 that it didn=92t get the =20
> matching feature of huge page support that ppc64 has? Who is =20
> responsible/willing to fix it?
The ppc32 HW doesn't support the same MMU features that ppc64 does.  =20
There's a possibility for something like tlbfs support using BATs, =20
but the normal MMU path doesn't have any HW capable of doing large =20
pages.

> 2)       Is it appropriate to provide a syscall mechanism (parallel =20=

> to sys_brk, sys_mmap, and sys_shmget) to add WIMG settings?
You can do some of this via mmap today.  I think O_SYNC is the flag =20
you need (well at least for mmap'ing /dev/mem).

> Overall, the vision here is to be able (from user-side, on =20
> powerpc32) to call:
>
>
>
> shmid =3D shmget(2, LENGTH, SHM_HUGETLB | IPC_CREAT | SHM_R | SHM_W | =20=

> POWERPC_NONCOHERENT);
>
> shmaddr =3D shmat(shmid, ADDR, SHMAT_FLAGS);
>
>
>
> And get a segment mapped with wimg=3D0bxx0x (actually, I assume all =20=

> x=92s are 0). This would be very nice!
>
>
>
>
>
> Thank you,
>
> -Ilya
>
>
>
> P.S. As a side note, it is pretty difficult to read kernel sources =20
> (especially assembly ones) because of the lack of comments for =20
> people who are not in the kernel hacker =93circle.=94 For example, =
what =20
> in the whole world is =93paca??=94
"paca" has to deal with the IBM HV interface.

- k=