Re: [PATCH 1/3] powerpc/32: Fix hugepage allocation on 8xx at hint address

From: Christophe LEROY
Date: Tue Jan 16 2018 - 11:53:17 EST




Le 16/01/2018 Ã 17:43, Aneesh Kumar K.V a ÃcritÂ:


On 01/16/2018 10:01 PM, Christophe LEROY wrote:


Le 16/01/2018 Ã 16:49, Aneesh Kumar K.V a ÃcritÂ:
Christophe Leroy <christophe.leroy@xxxxxx> writes:

When an app has some regular pages allocated (e.g. see below) and tries
to mmap() a huge page at a hint address covered by the same PMD entry,
the kernel accepts the hint allthough the 8xx cannot handle different
page sizes in the same PMD entry.


So that is a bug in get_unmapped_area function that you are using and
you want to fix that by using the slice code. Can you describe here what
the allocation restrictions are w.r.t 8xx? Do they have segments and
base page size like hash64?

I don't think it is a bug in get_unmapped_area() that is used by default. It is that some HW do support mixing any page size in the same page table (eg BOOK3E ?), but the 8xx doesn't.
In the 8xx, the page size is defined in the PGD entry, then all pages defined in a given page table pointed by a PGD entry have the same size.

So it is similar to segments if you consider each PGD entry as a kind of segment


so IIUC, hugepd format encodes the page size details and that require us to ensure that all the address range mapped at that hupge_pd entry is of same page size? Hence we want to avoid mmap handing over an address in that range when we already have a hugetlb mapping in that range?

Exactly

And also avoid hugetlb_get_unmapped_area() accepting an hint address in that range when we already have a regular mapping in that range.

Christophe