From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77DB9C04FFE for ; Mon, 20 May 2024 12:54:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D01D76B0082; Mon, 20 May 2024 08:54:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CB2616B0083; Mon, 20 May 2024 08:54:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B7A766B0085; Mon, 20 May 2024 08:54:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9C3216B0082 for ; Mon, 20 May 2024 08:54:45 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 39F11140D92 for ; Mon, 20 May 2024 12:54:45 +0000 (UTC) X-FDA: 82138768530.15.17C25A1 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf02.hostedemail.com (Postfix) with ESMTP id 5154280004 for ; Mon, 20 May 2024 12:54:43 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gYHDsZEU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of npiggin@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=npiggin@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716209683; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PsaS7hwC6SGwZpxPNV/aTtZM8wWRDwUCiBIx6wA+SRA=; b=S2NriNvClbPHWMqRsLIi6nky2TInl+hL0o4CDmzY7mtCLciTwUArf4Xe/Fw2DKLHaPzrlu +odv/ufvNkMg5MhrSQPDb6XEebN7IOwhmJG2U+gHCg2VogQfyvLnl/gXKxVSaNVbb9Qk5s VsIm8kuamJjaVcC13BLnxK3q8CZxq+Y= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gYHDsZEU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf02.hostedemail.com: domain of npiggin@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=npiggin@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716209683; a=rsa-sha256; cv=none; b=yXZJD7Ievx3yQmrCCi/983zmY+bsB2RWQOTIhBqW7IUSm4yDnFiwk11sJAv9SFwEPuBbmP mS4xWUe5qlzGtVsIq8iDPzPdBZHDVO+Gk9QdGI7x4lmIS63zEajJF2QxknAPvqx44QcFSg d5vCKNGCYyq6lKsrxbiCjzpVQoIV7c0= Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-1ee954e0aa6so41219545ad.3 for ; Mon, 20 May 2024 05:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1716209682; x=1716814482; darn=kvack.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PsaS7hwC6SGwZpxPNV/aTtZM8wWRDwUCiBIx6wA+SRA=; b=gYHDsZEUDtYHZXHFhrXvr7VzbJg3Ch4toIAWTUqQ7XAz0RHW6pqh+yXd92mw+slS1I Ts1n6mvX4jwCjud4GXciSwmmG2Z2NMmyDNdW9ZJ+Rx8dAL7LNPgRFE2nTomQRMvvWYbY WHB74v7xZgm/sDZDtMvnC7bzTrAIeDZnxMfzr4grlr+gbBxQcwswWUaoLT2FgS8C5C6X udPgdYK2XnCDmS0+28X/4yCarrGhxY0mhELm0hfN8Fo6XUxJ3P8WfsOZZxOKsja+Xbnl +SywYmgszfGtq1xW90IZWVVMSIwHWkSPI4r6QgfuYBHjMORlRmGbbelgctnWTBW9+b2a g77w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716209682; x=1716814482; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=PsaS7hwC6SGwZpxPNV/aTtZM8wWRDwUCiBIx6wA+SRA=; b=rqSmLEJ35qDH4cdX+HDTB0bufqmz37YDhaUJZVvZ1JWN8Ws1rYpZQF/xtSqRDqj3Y0 OZw1dmjM+yDZmMp08mdkcZCsTpdDQtHLm7N3fMNMnZSXJ8Zjb7qRh/9uiazi5vT2cxZc nWD2QDR0LAHUvUQ1ejF1Ca7uYSicgxoakcyYR2ixwih4Bb3oOadE3Fm4VzToyvoXU6Bg wohFqrVXQNGCMee+WLNqjKH3yBzecm1yaSpdlm6w9hRJlNQaeq9OKG9uV6GKNHp+Qdr4 HR6dYlc483TK3IPxlUh1YlJ2b+uxBfJGQACGzHdy/Fz3XxXpx+fGTlvGgk42Gz3nQ/LQ LbHQ== X-Forwarded-Encrypted: i=1; AJvYcCX5YcV226DMdieJsVwEQJolktxKOVTBKI6oDpsAVYEGuHD/9Pr3Cwm2vnZHIJhpT76juwwh6RVBQaSSYeX4YdJPMCI= X-Gm-Message-State: AOJu0YyD/pW9LMbhLgNkgbK9lM6Hbs6NTTUG9JYORVwX62+2Uxu+PcAL YudcwiHjSiGQXGWXA3hBNK0QB32opdVA9h4AV9/QkkosleIQ8DZh X-Google-Smtp-Source: AGHT+IGQD5voDad482etfAFYqJItSYWnKfB4jvZBywe8XpDGx+z9MFzihkDpII2A9KT8cmADi+Mg7g== X-Received: by 2002:a05:6a00:b51:b0:6ed:88e5:53d4 with SMTP id d2e1a72fcca58-6f4e02aa365mr35041612b3a.8.1716209682074; Mon, 20 May 2024 05:54:42 -0700 (PDT) Received: from localhost (110-175-65-7.tpgi.com.au. [110.175.65.7]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-6f4eccc3b91sm16004093b3a.66.2024.05.20.05.54.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 May 2024 05:54:41 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 20 May 2024 22:54:35 +1000 Message-Id: Cc: , , Subject: Re: [RFC PATCH v2 18/20] powerpc/64s: Use contiguous PMD/PUD instead of HUGEPD From: "Nicholas Piggin" To: "Christophe Leroy" , "Andrew Morton" , "Jason Gunthorpe" , "Peter Xu" , "Oscar Salvador" , "Michael Ellerman" X-Mailer: aerc 0.17.0 References: In-Reply-To: X-Rspamd-Queue-Id: 5154280004 X-Stat-Signature: x9xk6cqqjkyzx3rt79d3wmjeq15pqfjq X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1716209683-908597 X-HE-Meta: U2FsdGVkX18epNcvuD/WISPbt0//Q27YDSOPjFEVzZ3hAEzZAmUmytnp56akHe8bsdM53UBewRY36dRP7hNFS3Zz/AKWyTtkSjnHQDaFhwfao84M8K/gFb471nsDeTAItXBSCFypB2f7/BPRxLq7WIgj574r63k/k4XDEnsjiF8RNZ0+4GBueSv9X+4SGTU99bCbJzwZKGUalbRkSTcIiOLtvsR3a4Kmj7oAdsH/5yYu3QW/lIjz5dtFt4PdNjuPzT6Xru10XNls8xM/3LEEAC5xG2BqNfhAoqD0gWrvNRlNl5CeoiFWzwTvLZFs6K5osKeqlmXcYTteLmcLkaxOltiQxJe+unxVuQCJhm1eOY399V6U5zHzsGNw+gZ4EhRDAWJ+QucF8n7sAz9QkwTeNe6VGOIlmM0lf0s8LXWHfqv+hxYl24kIgJBtELkNXVmRV+JXx40t7+F68DYwzNyBuSkM1n4pvcQUzvFFMZxUccFcgXPo3XbG2M8VrE8vbeYc/8WzFD/k34yZdK7JsKMso9I5oKRbWDnIDoHExfWBDJzrwOdAJN3+QDaJyCv4NaDxlyCiKPg9uXU8hfFE0MxVPWFBHCl8dGDppbb9X8GYgWTd8XGJmC6RQsYq10SHNBYbX+f7b7FaD4VoYkHeKj7VSPwFlvqNWHM6dhkR4q4ncruZ7RXJmEfyrp/mer/N0AwiC9veAiTyM6BJ1AHCR634DFQveQuPLZLTvoWw6b/rq2mukiNZl09xm4U35pDUvVfhsR9bQcHsSs8R/fc8fpxWMV6i1ByQAyYjYBCM14B1PwDj/Be6XtcrHLqFbIgd5gq2M6I8Neb9l49Mg6wwaL+rRY1QKQubdgtvmUK8BXvJXA+DCITBoL0oXo6Q4axPjpnSl2m2SVfHGdV0i9SVgM6aOw/anTjuqalHr83f+ZEfU9cqAhGuFDUJgUeW44etJTBHi2Orflp2Bo2ImDvkOhW 23eoDmSE vWPt5INcvtR4vLadMvOc8iHNql0RTyUdTbzCIaSMBpkEO2JAYv3t6Uxg9gDAmCr0zxB3Tpm0dKed52Gy85m+nb4O2dICWBGg7inJftDB23zfFuHGyjFwlSuL9ngyPHJL2eTwc9vc9GUjPYdYbqzvVYnJryJd7zisZFQz4m9ZvCXALgTZ91yssK4vcZ+uLAA4EPDJPCfjxEW/NBut058SXlwbvvSbxytlE2WgjdiTq+BfIMMnxDki3u2gS2/GqLjaiA28fpkZ7VKUNGwUeDPFLF2nIA+aqT9oJJ6qLFevvV9AG0d3ioDcxu7bcJSJJ3GR1A4k5CWqRN1pvAwqONGC8RgLN9CHOM4ZQeSjKUTxgMvJTXCzZjDFyT7ZI1JRC/EhyYNLD/RM2iKSsJ7ilKheHFS31l93soVpOREI+wsBqlYnxOUv4l+lkZpWCtUjmXQRIRRNb0iCf2xADY5o1veMcK3c41PoCcTCvH3+uWxQzd22wcZqagfTSRPjNGmjh6UcRY6VGEgTkk1Sw35c= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sat May 18, 2024 at 5:00 AM AEST, Christophe Leroy wrote: > On book3s/64, the only user of hugepd is hash in 4k mode. > > All other setups (hash-64, radix-4, radix-64) use leaf PMD/PUD. > > Rework hash-4k to use contiguous PMD and PUD instead. > > In that setup there are only two huge page sizes: 16M and 16G. > > 16M sits at PMD level and 16G at PUD level. > > pte_update doesn't know page size, lets use the same trick as > hpte_need_flush() to get page size from segment properties. That's > not the most efficient way but let's do that until callers of > pte_update() provide page size instead of just a huge flag. > > Signed-off-by: Christophe Leroy > --- > arch/powerpc/include/asm/book3s/64/hash-4k.h | 15 -------- > arch/powerpc/include/asm/book3s/64/hash.h | 38 +++++++++++++++---- > arch/powerpc/include/asm/book3s/64/hugetlb.h | 38 ------------------- > .../include/asm/book3s/64/pgtable-4k.h | 34 ----------------- > .../include/asm/book3s/64/pgtable-64k.h | 20 ---------- > arch/powerpc/include/asm/hugetlb.h | 4 ++ > .../include/asm/nohash/32/hugetlb-8xx.h | 4 -- > .../powerpc/include/asm/nohash/hugetlb-e500.h | 4 -- > arch/powerpc/include/asm/page.h | 8 ---- > arch/powerpc/mm/book3s64/hash_utils.c | 11 ++++-- > arch/powerpc/mm/book3s64/pgtable.c | 12 ------ > arch/powerpc/mm/hugetlbpage.c | 19 ---------- > arch/powerpc/mm/pgtable.c | 2 +- > arch/powerpc/platforms/Kconfig.cputype | 1 - > 14 files changed, 43 insertions(+), 167 deletions(-) > > diff --git a/arch/powerpc/include/asm/book3s/64/hash-4k.h b/arch/powerpc/= include/asm/book3s/64/hash-4k.h > index 6472b08fa1b0..c654c376ef8b 100644 > --- a/arch/powerpc/include/asm/book3s/64/hash-4k.h > +++ b/arch/powerpc/include/asm/book3s/64/hash-4k.h > @@ -74,21 +74,6 @@ > #define remap_4k_pfn(vma, addr, pfn, prot) \ > remap_pfn_range((vma), (addr), (pfn), PAGE_SIZE, (prot)) > =20 > -#ifdef CONFIG_HUGETLB_PAGE > -static inline int hash__hugepd_ok(hugepd_t hpd) > -{ > - unsigned long hpdval =3D hpd_val(hpd); > - /* > - * if it is not a pte and have hugepd shift mask > - * set, then it is a hugepd directory pointer > - */ > - if (!(hpdval & _PAGE_PTE) && (hpdval & _PAGE_PRESENT) && > - ((hpdval & HUGEPD_SHIFT_MASK) !=3D 0)) > - return true; > - return false; > -} > -#endif > - > /* > * 4K PTE format is different from 64K PTE format. Saving the hash_slot = is just > * a matter of returning the PTE bits that need to be modified. On 64K P= TE, > diff --git a/arch/powerpc/include/asm/book3s/64/hash.h b/arch/powerpc/inc= lude/asm/book3s/64/hash.h > index faf3e3b4e4b2..509811ca7695 100644 > --- a/arch/powerpc/include/asm/book3s/64/hash.h > +++ b/arch/powerpc/include/asm/book3s/64/hash.h > @@ -4,6 +4,7 @@ > #ifdef __KERNEL__ > =20 > #include > +#include > =20 > /* > * Common bits between 4K and 64K pages in a linux-style PTE. > @@ -161,14 +162,10 @@ extern void hpte_need_flush(struct mm_struct *mm, u= nsigned long addr, > pte_t *ptep, unsigned long pte, int huge); > unsigned long htab_convert_pte_flags(unsigned long pteflags, unsigned lo= ng flags); > /* Atomic PTE updates */ > -static inline unsigned long hash__pte_update(struct mm_struct *mm, > - unsigned long addr, > - pte_t *ptep, unsigned long clr, > - unsigned long set, > - int huge) > +static inline unsigned long hash__pte_update_one(pte_t *ptep, unsigned l= ong clr, > + unsigned long set) > { > __be64 old_be, tmp_be; > - unsigned long old; > =20 > __asm__ __volatile__( > "1: ldarx %0,0,%3 # pte_update\n\ > @@ -182,11 +179,38 @@ static inline unsigned long hash__pte_update(struct= mm_struct *mm, > : "r" (ptep), "r" (cpu_to_be64(clr)), "m" (*ptep), > "r" (cpu_to_be64(H_PAGE_BUSY)), "r" (cpu_to_be64(set)) > : "cc" ); > + > + return be64_to_cpu(old_be); > +} > + > +static inline unsigned long hash__pte_update(struct mm_struct *mm, > + unsigned long addr, > + pte_t *ptep, unsigned long clr, > + unsigned long set, > + int huge) > +{ > + unsigned long old; > + > + old =3D hash__pte_update_one(ptep, clr, set); > + > + if (huge && IS_ENABLED(CONFIG_PPC_4K_PAGES)) { > + unsigned int psize =3D get_slice_psize(mm, addr); > + int nb, i; > + > + if (psize =3D=3D MMU_PAGE_16M) > + nb =3D SZ_16M / PMD_SIZE; > + else if (psize =3D=3D MMU_PAGE_16G) > + nb =3D SZ_16G / PUD_SIZE; > + else > + nb =3D 1; > + > + for (i =3D 1; i < nb; i++) > + hash__pte_update_one(ptep + i, clr, set); > + } > /* huge pages use the old page table lock */ > if (!huge) > assert_pte_locked(mm, addr); > =20 > - old =3D be64_to_cpu(old_be); > if (old & H_PAGE_HASHPTE) > hpte_need_flush(mm, addr, ptep, old, huge); > =20 Nice series, I don't know this hugepd code very well but I'll try. Why do you have to replicate the PTE entry here? The hash table refill should always be working on the first PTE of the page otherwise we have bigger problems. What paths look at the N > 0 PTEs of a contiguous page entry? Thanks, Nick