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 39AD2C25B75 for ; Wed, 29 May 2024 08:49:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CB21B6B00AC; Wed, 29 May 2024 04:49:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C63046B00AD; Wed, 29 May 2024 04:49:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B2B1B6B00AE; Wed, 29 May 2024 04:49:28 -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 94D8E6B00AC for ; Wed, 29 May 2024 04:49:28 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1622C120BF9 for ; Wed, 29 May 2024 08:49:28 +0000 (UTC) X-FDA: 82170809616.19.455FF0A Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf16.hostedemail.com (Postfix) with ESMTP id 316F318002C for ; Wed, 29 May 2024 08:49:24 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Bvb4RJYs; spf=pass (imf16.hostedemail.com: domain of osalvador@suse.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=osalvador@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716972565; a=rsa-sha256; cv=none; b=IFzY1bqBfgs3/Gk1awUWOecSaPmsHOFN2vlW1lE9nfeTl63TCSQxohu/rHKOBzqgUa9Aoy v1uOLv0NcXSspqQeQrUdjM7WRWKIDCN5qm3omAfQiIbjWNTm3K2jRMHKD6KnXrCv2Krgc2 v8Wrd7ECzSUgog8OFH22ZbGOagfR4O8= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=Bvb4RJYs; spf=pass (imf16.hostedemail.com: domain of osalvador@suse.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=osalvador@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1716972565; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8FqWscTuoS7Z7zXndqslsCK2s/b+E7GOJQ0fFCGFa0k=; b=zdLj11ewZ9uKJhMRwEzV11Fi6GqGhkE1BPNfzimIRTGEGj3RFWI60MlkL0wMLufTLprMC1 KvNPOPyA1V1DMotM3UdWWcuglVnp0q3xbCjT+vye+bZWtULJXZqRbbdNh+yh9fZ2jbUPKr FNcHQkNhFubI+u1bXLbLGRx1DpYcBVs= Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4202c1d19d5so15642675e9.2 for ; Wed, 29 May 2024 01:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1716972563; x=1717577363; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=8FqWscTuoS7Z7zXndqslsCK2s/b+E7GOJQ0fFCGFa0k=; b=Bvb4RJYsqfX2B4I9eqK7FtWo2Ofg9Q7o2sUYTNzc/jMpfU7bOeLg+TgQkKATItrM2e iC1mJWHhqe+Ea0vwdHaaoaMFUH9WaBGIdtD2PFT7wJfDCim/ToIkEi5w0eF6y8wrNRsf Crw6pswxhIpbZe8/qMv5LV9rKxRQDeYbBBq8rP9174DUex/0BvVcmXYLpdG/wP81d1hi WDMgb3O/gt77Z0f38OzpcreivulH9mC9fwdFmrbfeJMwZ32Yurh5sUYCuXuTqAzpwztL TRd2JeDJIc644NLredn/5wy38SExvAWUMDp8oEM1h9ZCK4gFjiYbu77KMr+XSoKcnmJM PVxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716972563; x=1717577363; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8FqWscTuoS7Z7zXndqslsCK2s/b+E7GOJQ0fFCGFa0k=; b=GmOCOicJMboMNEueyAmE4mloNsmnh3EdOwjqbabaCZU8YCkAZu1GLBygV+gtgCuoq1 JSZYRRj/m6jGK/Bf6EWOLFjAuxSqcmd2DJO4mqE8lenyFtRAF6Sl8iXsOja6RIQFAphM SKmXHyevfc+4+XmyC6UyBqjaB2zz8MgPMA6wAru10TJTfZThyjGBV0I4zCkz6wHqdHEr YOjcxw6KEUvDMwzRvPe2utgaWgxFOLQsO9hjMaYofrAsVysfNQlDfsDLLEvKLY2yqNPe m4FXJIa2QZi1+qdm9FiflmwyZbVcpZ6ChCsuJPssFcmu55xPwbN594yRbvgurpgBRWqH JWbg== X-Forwarded-Encrypted: i=1; AJvYcCXtnt/zEnv7XjGJPUHfFrRQ1HbKjgXkB7W14T/3GQakwleRc6cQ2aC46Rh5xYOEabHBkYBLbmXJgALqAcBUWId95mA= X-Gm-Message-State: AOJu0YxJiscq8mvxPSKZQGz+G1uYSbp14/zTnjIGhgRxLCpvc4KTUtNT J43lJ1s/MCTU7GLBYSQDmU+ovERWVQBdNmE6BxujbcR3LTtr+HY5nUIhouQEb9A= X-Google-Smtp-Source: AGHT+IFirCm930ok6c0waccClyLojOOhDizCBj1LVv0U/qJp1ipt5v04MsZ7oUfrdlcX266KE3FIUw== X-Received: by 2002:a05:600c:224e:b0:420:fb99:ed02 with SMTP id 5b1f17b1804b1-421089b2283mr134252545e9.6.1716972563537; Wed, 29 May 2024 01:49:23 -0700 (PDT) Received: from localhost.localdomain (62.83.84.125.dyn.user.ono.com. [62.83.84.125]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42100ee806esm204152935e9.3.2024.05.29.01.49.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 May 2024 01:49:23 -0700 (PDT) From: Oscar Salvador X-Google-Original-From: Oscar Salvador Date: Wed, 29 May 2024 10:49:21 +0200 To: Christophe Leroy Cc: Andrew Morton , Jason Gunthorpe , Peter Xu , Michael Ellerman , Nicholas Piggin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC PATCH v4 13/16] powerpc/e500: Use contiguous PMD instead of hugepd Message-ID: References: <56cf925576285e2b97550f4f7317183d98d596c5.1716815901.git.christophe.leroy@csgroup.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56cf925576285e2b97550f4f7317183d98d596c5.1716815901.git.christophe.leroy@csgroup.eu> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 316F318002C X-Stat-Signature: 414m7y4695mttktahtyzfxpih85aa1i5 X-HE-Tag: 1716972564-337264 X-HE-Meta: U2FsdGVkX19m5OuJkZAQm6LjtXQn69gfy+5MItsJdteSPrmKX+gXp14e86lYX1qsbEkFmfvDt2oV6yOQ0ZdP40Y2uFXK5fUFec1QeRBQkIJjtWg1GmiomX+DSONNJJ2Z7b76RkCEjsp7+tMIQpFqoIcdEf1N5fc9rEzHD7vUsUEffE10Ks+ZggQtjw0tMNfXsZcqL++4FVcdzXvZHmmDxmwPd2VoP6VVHabBBoLWDa1aX7Ryg4z1AkXYS92xI2xbEoSqvNHSi8+tKdKGyM57dcTWwCJWtdicZQxwyT8OgZD68FAIrPtJbUYGXakcwVR/tG+l9PTbdez5f6Wtwz1uG9PY41+hpcHEqtDZkEk14ICiG3FBAxtmTq3PugxfYgnp8vdxIs/tiptj+gbb5yJPAOMJm2OThnKyPamE+xWd7MZSNcQgxjr0e6cU2/t0uHamyqqp7Nd1Z4DkxrUnmDWa+f7LpqYOM73z+qvYyCqlRBry7LNRitMp670ndlfDKQr3st/saKiF77ac/GSy3fE6C3SzB5a1SomaqWpQvjdD8sbd0mtDRSlN84ndpwITNnvAkRfmdXIYv8aR3pgaZchaNNyohOgqrts4nGPa3MeqTDFnFPFGYg63QkSJ6YJWr8zE6ae6/77pzCWaPrksLtHe1WDCRGmTWQdksPQRcT3kfSj1AZAMXvqhfenLqU8z5+5z9S9PqrrHRMZ6NinHdP3eU/aQqpnmHfC7G6QEdPvKto4UJ4iqM675ZhbT4h/umis9T3kUkg2qu82Wgv/G+faK2zASaj7HOMR61Q6d3RWRYEGZGXgRKcB2Sbxq/Fw9H975+x1srJspgA9FUnUJ/cYRADMhJ7TetTg3HMEMxwO9E5xGnM7P2toJi8TbH7K7BMOiS74MMaq5rvsJrL1xuDcsdA7yOAUpLf5GB+nkysX1M1MeXLjzGsswlCpuCuTCv9suwch8BaIL52VneqxHQpk kXAxeQCV g+XcGHnStpSRBGv5/fiXmn+A7qJofGuOQUDZW+cEjb85YG6ysnJnFy7O24BGuLmPAxNg8mhQdjq0i1aWK0K1BT2gZpk0ijSefX4uNFgBu1R+Rx6jyr7+f2rD/aBt44xUjJsxOe2Xp09OL8646o0RhdO8ZbVwYJ5WfLYszONYaGElZHIfIfAWT0I72DFLQFAi6KPOMzE7tGUknfK7T9VD/TPoxp5kPQUMrOh1ADWk6xjcgfcUh/su0yIrDen0jNfFBuVB20Jg5jm6x0KSNNH0pyIrRF1P+M171bPAC1rFbSC7qU6huC7eOgjCJa+LbsfktM9uvW5y/jvbzX3TqKZEF+6x8Pk5opJaJrDCiTitSkrSHyis= 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 Mon, May 27, 2024 at 03:30:11PM +0200, Christophe Leroy wrote: > e500 supports many page sizes among which the following size are > implemented in the kernel at the time being: 4M, 16M, 64M, 256M, 1G. > > On e500, TLB miss for hugepages is exclusively handled by SW even > on e6500 which has HW assistance for 4k pages, so there are no > constraints like on the 8xx. > > On e500/32, all are at PGD/PMD level and can be handled as > cont-PMD. > > On e500/64, smaller ones are on PMD while bigger ones are on PUD. > Again, they can easily be handled as cont-PMD and cont-PUD instead > of hugepd. > > Signed-off-by: Christophe Leroy ... > diff --git a/arch/powerpc/include/asm/nohash/pgtable.h b/arch/powerpc/include/asm/nohash/pgtable.h > index 90d6a0943b35..f7421d1a1693 100644 > --- a/arch/powerpc/include/asm/nohash/pgtable.h > +++ b/arch/powerpc/include/asm/nohash/pgtable.h > @@ -52,11 +52,36 @@ static inline pte_basic_t pte_update(struct mm_struct *mm, unsigned long addr, p > { > pte_basic_t old = pte_val(*p); > pte_basic_t new = (old & ~(pte_basic_t)clr) | set; > + unsigned long sz; > + unsigned long pdsize; > + int i; > > if (new == old) > return old; > > - *p = __pte(new); > +#ifdef CONFIG_PPC_E500 > + if (huge) > + sz = 1UL << (((old & _PAGE_HSIZE_MSK) >> _PAGE_HSIZE_SHIFT) + 20); > + else I think this will not compile when CONFIG_PPC_85xx && !CONFIG_PTE_64BIT. You have declared _PAGE_HSIZE_MSK and _PAGE_HSIZE_SHIFT in arch/powerpc/include/asm/nohash/hugetlb-e500.h. But hugetlb-e500.h is only included if CONFIG_PPC_85xx && CONFIG_PTE_64BIT (see arch/powerpc/include/asm/nohash/32/pgtable.h). > +#endif > + sz = PAGE_SIZE; > + > + if (!huge || sz < PMD_SIZE) > + pdsize = PAGE_SIZE; > + else if (sz < PUD_SIZE) > + pdsize = PMD_SIZE; > + else if (sz < P4D_SIZE) > + pdsize = PUD_SIZE; > + else if (sz < PGDIR_SIZE) > + pdsize = P4D_SIZE; > + else > + pdsize = PGDIR_SIZE; > + > + for (i = 0; i < sz / pdsize; i++, p++) { > + *p = __pte(new); > + if (new) > + new += (unsigned long long)(pdsize / PAGE_SIZE) << PTE_RPN_SHIFT; I guess 'new' can be 0 if pte_update() is called on behave of clearing the pte? > +static inline unsigned long pmd_leaf_size(pmd_t pmd) > +{ > + return 1UL << (((pmd_val(pmd) & _PAGE_HSIZE_MSK) >> _PAGE_HSIZE_SHIFT) + 20); Can we have the '20' somewhere defined with a comment on top explaining what is so it is not a magic number? Otherwise people might come look at this and wonder why 20. > --- a/arch/powerpc/mm/pgtable.c > +++ b/arch/powerpc/mm/pgtable.c > @@ -331,6 +331,37 @@ void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, > __set_huge_pte_at(pmdp, ptep, pte_val(pte)); > } > } > +#elif defined(CONFIG_PPC_E500) > +void set_huge_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, > + pte_t pte, unsigned long sz) > +{ > + unsigned long pdsize; > + int i; > + > + pte = set_pte_filter(pte, addr); > + > + /* > + * Make sure hardware valid bit is not set. We don't do > + * tlb flush for this update. > + */ > + VM_WARN_ON(pte_hw_valid(*ptep) && !pte_protnone(*ptep)); > + > + if (sz < PMD_SIZE) > + pdsize = PAGE_SIZE; > + else if (sz < PUD_SIZE) > + pdsize = PMD_SIZE; > + else if (sz < P4D_SIZE) > + pdsize = PUD_SIZE; > + else if (sz < PGDIR_SIZE) > + pdsize = P4D_SIZE; > + else > + pdsize = PGDIR_SIZE; > + > + for (i = 0; i < sz / pdsize; i++, ptep++, addr += pdsize) { > + __set_pte_at(mm, addr, ptep, pte, 0); > + pte = __pte(pte_val(pte) + ((unsigned long long)pdsize / PAGE_SIZE << PFN_PTE_SHIFT)); You can use pte_advance_pfn() here? Just give have nr = (unsigned long long)pdsize / PAGE_SIZE << PFN_PTE_SHIFT) pte_advance_pfn(pte, nr) Which 'sz's can we have here? You mentioned that e500 support: 4M, 16M, 64M, 256M, 1G. which of these ones can be huge? -- Oscar Salvador SUSE Labs