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

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

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

quoted

Le 16/01/2018 à 16:49, Aneesh Kumar K.V a écrit :

quoted

Christophe Leroy [off-list ref] writes:

quoted

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