From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752886AbcHOKXQ convert rfc822-to-8bit (ORCPT ); Mon, 15 Aug 2016 06:23:16 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:39317 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752748AbcHOKXO (ORCPT ); Mon, 15 Aug 2016 06:23:14 -0400 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: aneesh.kumar@linux.vnet.ibm.com From: "Aneesh Kumar K.V" To: christophe leroy , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Scott Wood Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/6] powerpc: port 64 bits pgtable_cache to 32 bits In-Reply-To: References: <794b4abd8caaad32edf4180ac485a2eb914fba49.1471020647.git.christophe.leroy@c-s.fr> <878tvza0zg.fsf@skywalker.in.ibm.com> Date: Mon, 15 Aug 2016 15:53:03 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16081510-0008-0000-0000-0000054E1429 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005597; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000181; SDB=6.00744903; UDB=6.00350997; IPR=6.00517456; BA=6.00004662; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012336; XFM=3.00000011; UTC=2016-08-15 10:23:11 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16081510-0009-0000-0000-00003A3E8B55 Message-Id: <87fuq649h4.fsf@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-15_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608150121 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org christophe leroy writes: > Le 14/08/2016 à 16:17, Aneesh Kumar K.V a écrit : >> Christophe Leroy writes: >> >>> Today powerpc64 uses a set of pgtable_caches while powerpc32 uses >>> standard pages when using 4k pages and a single pgtable_cache >>> if using other size pages. In addition powerpc32 uses another cache >>> when handling huge pages. >>> >>> In preparation of implementing huge pages on the 8xx, this patch >>> replaces the specific powerpc32 handling by the 64 bits approach. >> >> Why is this needed ? Can you also summarize the page size used and the >> hugepage format you are planning to use ? . What are the page sizes >> supported by 8xx ? Also is the new code copy of existing powerpc64 4k >> page size code ? > > 8xx supports two huge page sizes: 8M and 512k. > As PGD entries points on 4M page tables, it means we are in an > eterogenous situation: > 1/ when using 8M huge pages, we are in the same situation as what is > done for the BOOK3S (which supports 16M, 256M and 1G), that is several > PDG entries pointing to a single PTE entry. what is done for FSL BOOK3E ? > 2/ when using 512k huge pages, we are in the same situation as whan is > done for the BOOK3E: a PGD entry points to the hugepage table that > handles several huge pages (in our case 8 huge pages) > what is done for Book3s with 4K linux page size. ? So the idea here is to allocate different hugepte table based on hugepage size requested and hence the need to switch from hugpte-cache to a more generic PGT_CACHE ? > The code from init_64 have been moved to a new file named init-common in > order to be used by init_32 too. > The code from the 64 bits .h has been copied into the 32 bits .h (indeed > it's been copied twice as the .h are now duplicated into nohash and > book3s versions) That explanation made it a lot easy to follow the patch. Can we capture that in commit message too. Also Do we support hugepage with both 4k and 16K linux page size ?. I guess we do because 8xx only do a two level linux page table ? > > [...] > >>> diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c >>> index 7372ee1..9164a77 100644 >>> --- a/arch/powerpc/mm/hugetlbpage.c >>> +++ b/arch/powerpc/mm/hugetlbpage.c >>> @@ -68,7 +68,7 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp, >>> #ifdef CONFIG_PPC_FSL_BOOK3E >>> int i; >>> int num_hugepd = 1 << (pshift - pdshift); >>> - cachep = hugepte_cache; >>> + cachep = PGT_CACHE(1); >>> #else >>> cachep = PGT_CACHE(pdshift - pshift); >>> #endif >> >> Can you explain the usage of PGT_CACHE(1) ? > > [...] > >> >> I still didn't quiet follow why we are replacing >> >> - hugepte_cache = kmem_cache_create("hugepte-cache", sizeof(pte_t), >> - HUGEPD_SHIFT_MASK + 1, 0, NULL); >> + pgtable_cache_add(1, NULL); >> > > Euh ... Indeed I wanted something to replace hugepte_cache. But it looks > like it should be something like PGT_CACHE(0) for 32 bits targets having > 32 bits PTEs and PGT_CACHE(1) for 32 bits targets having 64 bits PTEs. > But PGT_CACHE(0) doesn't exist (yet). > > Looking once more, that might not really be needed I think. I'll rework > it and see what I can achieve. > Thanks -aneesh