From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 42F1Sb4vWLzF0fh for ; Tue, 18 Sep 2018 21:47:27 +1000 (AEST) Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w8IBiTb4127992 for ; Tue, 18 Sep 2018 07:47:25 -0400 Received: from e06smtp07.uk.ibm.com (e06smtp07.uk.ibm.com [195.75.94.103]) by mx0a-001b2d01.pphosted.com with ESMTP id 2mjwweytm1-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 18 Sep 2018 07:47:25 -0400 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 18 Sep 2018 12:47:22 +0100 From: "Aneesh Kumar K.V" To: Christophe LEROY , akpm@linux-foundation.org, linux-mm@kvack.org, aneesh.kumar@linux.vnet.ibm.com, Nicholas Piggin , Michael Ellerman , linuxppc-dev@lists.ozlabs.org Cc: LKML Subject: Re: How to handle PTE tables with non contiguous entries ? In-Reply-To: References: <87tvmoh4w9.fsf@linux.ibm.com> Date: Tue, 18 Sep 2018 17:17:16 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Message-Id: <87pnxbgh8b.fsf@linux.ibm.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Christophe LEROY writes: > Le 17/09/2018 =C3=A0 11:03, Aneesh Kumar K.V a =C3=A9crit=C2=A0: >> Christophe Leroy writes: >>=20 >>> Hi, >>> >>> I'm having a hard time figuring out the best way to handle the following >>> situation: >>> >>> On the powerpc8xx, handling 16k size pages requires to have page tables >>> with 4 identical entries. >>=20 >> I assume that hugetlb page size? If so isn't that similar to FSL hugetlb >> page table layout? > > No, it is not for 16k hugepage size with a standard page size of 4k. > > Here I'm trying to handle the case of CONFIG_PPC_16K_PAGES. > As of today, it is implemented by using the standard Linux page layout,=20 > ie one PTE entry for each 16k page. This forbids the use the 8xx HW=20 > assistance. > >>=20 >>> >>> Initially I was thinking about handling this by simply modifying >>> pte_index() which changing pte_t type in order to have one entry every >>> 16 bytes, then replicate the PTE value at *ptep, *ptep+1,*ptep+2 and >>> *ptep+3 both in set_pte_at() and pte_update(). >>> >>> However, this doesn't work because many many places in the mm core part >>> of the kernel use loops on ptep with single ptep++ increment. >>> >>> Therefore did it with the following hack: >>> >>> /* PTE level */ >>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES) >>> +typedef struct { pte_basic_t pte, pte1, pte2, pte3; } pte_t; >>> +#else >>> typedef struct { pte_basic_t pte; } pte_t; >>> +#endif >>> >>> @@ -181,7 +192,13 @@ static inline unsigned long pte_update(pte_t *p, >>> : "cc" ); >>> #else /* PTE_ATOMIC_UPDATES */ >>> unsigned long old =3D pte_val(*p); >>> - *p =3D __pte((old & ~clr) | set); >>> + unsigned long new =3D (old & ~clr) | set; >>> + >>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES) >>> + p->pte =3D p->pte1 =3D p->pte2 =3D p->pte3 =3D new; >>> +#else >>> + *p =3D __pte(new); >>> +#endif >>> #endif /* !PTE_ATOMIC_UPDATES */ >>> >>> #ifdef CONFIG_44x >>> >>> >>> @@ -161,7 +161,11 @@ static inline void __set_pte_at(struct mm_struct >>> *mm, unsigned long addr, >>> /* Anything else just stores the PTE normally. That covers all >>> 64-bit >>> * cases, and 32-bit non-hash with 32-bit PTEs. >>> */ >>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PPC_16K_PAGES) >>> + ptep->pte =3D ptep->pte1 =3D ptep->pte2 =3D ptep->pte3 =3D pte_= val(pte); >>> +#else >>> *ptep =3D pte; >>> +#endif >>> >>> >>> >>> But I'm not too happy with it as it means pte_t is not a single type >>> anymore so passing it from one function to the other is quite heavy. >>> >>> >>> Would someone have an idea of an elegent way to handle that ? >>> >>> Thanks >>> Christophe >>=20 >> Why would pte_update bother about updating all the 4 entries?. Can you >> help me understand the issue? > > Because the 8xx HW assistance expects 4 identical entries for each 16k=20 > page, so everytime a PTE is updated the 4 entries have to be updated. > What you suggested in the original mail is what matches that best isn't it? That is a linux pte update involves updating 4 slot. Hence a linux pte consist of 4 unsigned long? -aneesh