From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752829AbcHOKaY convert rfc822-to-8bit (ORCPT ); Mon, 15 Aug 2016 06:30:24 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:47225 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752415AbcHOKaX (ORCPT ); Mon, 15 Aug 2016 06:30:23 -0400 X-IBM-Helo: d01dlp01.pok.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: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 6/6] powerpc/8xx: implementation of huge pages In-Reply-To: <55f9f338-a098-96e0-c753-2e83045bedab@c-s.fr> References: <15e0fa7a312245e681cb9ca18ffb875c7820e5fc.1471020647.git.christophe.leroy@c-s.fr> <8760r3a0md.fsf@skywalker.in.ibm.com> <55f9f338-a098-96e0-c753-2e83045bedab@c-s.fr> Date: Mon, 15 Aug 2016 16:00:14 +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-0056-0000-0000-0000010D6DBC 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.00744905; UDB=6.00350999; IPR=6.00517459; 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:30:20 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16081510-0057-0000-0000-00000527BF56 Message-Id: <87d1la4955.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-1608150123 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:25, Aneesh Kumar K.V a écrit : >> Christophe Leroy writes: >> >>> The 8xx has 512k and 8M pages. This patch implements hugepages using >>> those sizes. >>> >>> On the 8xx, the size of pages is in the PGD entry, >>> using PS field (bits 28-29): >>> 00 : Small pages (4k or 16k) >>> 01 : 512k pages >>> 10 : reserved >>> 11 : 8M pages >>> >>> The implementation uses a mix of what is used on BOOKS and BOOKE, >>> as 512k pages are in HUGEPTE tables while for 8M pages we have >>> several PGD entries pointing on a leaf HUGEPTE entry >>> >>> For the time being, we do not support CPU15 ERRATA if HUGETLB is >>> selected >> >> Can you also document here the format for linux page table with different >> huge page size. ? > > Euh ... isn't it what I do when explaining the use of the PS field in > the PGD entry ? That's the thing, that's how the 8xx knows how it is a > huge page, and that's how Linux will know it is one. On the 8xx, the > Linux PGD entry (almost) match the L1 MMU entry and the Linux PTE almost > match the L2 MMU entry (some bits are copied from the PTE to the L1 > entry and then removed from the value writen to the L2 MMU entry) > Sorry if that answer was obvious in the commit message. I haven't looked at 8xx pagetable format closely to understand the details. Now with your reply to the earlier email, I looked at the changes again and wonder whether we can document details like. 8xx uses a two level page table with two different linux page size support (4k and 16k). 8xx also support two different hugepage sizes 512k and 8M. Inorder to support then on linux we define two different page table layout. For 512K hugepage size a pgd entry have the below format [0100] . The hugepte table allocated will contain entries pointing to 512K huge pte. For 8M multiple pgd entries point to the same hugepte address. and pgd entry will have the below format [1100]. The hugepte table allocated will only have one entry. I agree that this is the same details you explained in the commit messages. But calling out all details will help anybody reading the code later. -aneesh