Messages in this thread | | | Subject | Re: [PATCH 1/3] powerpc/32: Fix hugepage allocation on 8xx at hint address | From | Christophe LEROY <> | Date | Tue, 16 Jan 2018 17:53:07 +0100 |
| |
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@c-s.fr> 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
| |