Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751925AbeAPQxN (ORCPT + 1 other); Tue, 16 Jan 2018 11:53:13 -0500 Received: from pegase1.c-s.fr ([93.17.236.30]:47773 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751284AbeAPQxK (ORCPT ); Tue, 16 Jan 2018 11:53:10 -0500 Subject: Re: [PATCH 1/3] powerpc/32: Fix hugepage allocation on 8xx at hint address To: "Aneesh Kumar K.V" , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Scott Wood , Nicholas Piggin Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org References: <9a5dadc10f88e2fc0ac9fb5d18c5424df33f3f4c.1515169256.git.christophe.leroy@c-s.fr> <876081by7g.fsf@linux.vnet.ibm.com> From: Christophe LEROY Message-ID: <003fc691-074a-9226-3ab2-69ff4a76f871@c-s.fr> Date: Tue, 16 Jan 2018 17:53:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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 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