Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751402AbeAPQnx (ORCPT + 1 other); Tue, 16 Jan 2018 11:43:53 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:42528 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750869AbeAPQnv (ORCPT ); Tue, 16 Jan 2018 11:43:51 -0500 Subject: Re: [PATCH 1/3] powerpc/32: Fix hugepage allocation on 8xx at hint address To: Christophe LEROY , 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: "Aneesh Kumar K.V" Date: Tue, 16 Jan 2018 22:13:39 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; 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: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18011616-0020-0000-0000-00000D4F85C6 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008389; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000246; SDB=6.00975917; UDB=6.00494672; IPR=6.00755844; BA=6.00005781; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00019073; XFM=3.00000015; UTC=2018-01-16 16:43:48 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18011616-0021-0000-0000-00005FB7A0D5 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-16_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1801160232 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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? -aneesh