Messages in this thread | | | Subject | Re: [PATCH v2] powerpc/mm: Fix growth direction for hugepages mmaps with slice | From | "Aneesh Kumar K.V" <> | Date | Wed, 17 Jan 2018 08:49:03 +0530 |
| |
On 01/16/2018 10:18 PM, Christophe LEROY wrote: > > > Le 16/01/2018 à 17:03, Aneesh Kumar K.V a écrit : >> Christophe Leroy <christophe.leroy@c-s.fr> writes: >> >>> An application running with libhugetlbfs fails to allocate >>> additional pages to HEAP due to the hugemap being done >>> inconditionally as topdown mapping: >>> >>> mmap(0x10080000, 1572864, PROT_READ|PROT_WRITE, >>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0) = 0x73e80000 >>> [...] >>> mmap(0x74000000, 1048576, PROT_READ|PROT_WRITE, >>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d80000 >>> munmap(0x73d80000, 1048576) = 0 >>> [...] >>> mmap(0x74000000, 1572864, PROT_READ|PROT_WRITE, >>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d00000 >>> munmap(0x73d00000, 1572864) = 0 >>> [...] >>> mmap(0x74000000, 1572864, PROT_READ|PROT_WRITE, >>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d00000 >>> munmap(0x73d00000, 1572864) = 0 >>> [...] >>> >> >> Can you explain the failure details above. I am not sure I understand >> what to read from the above output. > > libhugetlbfs first requests an area of size 1.5Mbytes, at address > 0x10080000 > mmap() returns an area at address 0x73e80000 > > Then libhugetlbfs requests an additional area on top of that, ie at > address 0x74000000, to expand the heap. > But mmap() returns an area at address 0x73d80000, ie under the previous > area. >
Can you share the test details?. Why does it not fail on book3s64? We use topdown search with book3s64.
> This is not the behaviour when using the generic (ie without mm_slices) > hugepages code, and this is not what libhugetlbfs expects for expending > the heap. > >
-aneesh
| |