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 D3559ECAAD3 for ; Sun, 4 Sep 2022 11:32:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 622C58018C; Sun, 4 Sep 2022 07:32:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D2558D0030; Sun, 4 Sep 2022 07:32:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 499D18018C; Sun, 4 Sep 2022 07:32:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 37DC48D0030 for ; Sun, 4 Sep 2022 07:32:44 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id DAED240B38 for ; Sun, 4 Sep 2022 11:32:43 +0000 (UTC) X-FDA: 79874190606.27.775BCDB Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by imf03.hostedemail.com (Postfix) with ESMTP id 3E53E2005F for ; Sun, 4 Sep 2022 11:32:43 +0000 (UTC) Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4ML8dh0h9pz4xD3; Sun, 4 Sep 2022 21:32:40 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1662291160; bh=mLGcxzbnnbxu6EKrXGdhCH+nPAYj+1VHsPHafBchnyw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QnNmWbRCa0lnHBgLJ47GutZ6jrIQhZ1hDyo8cLtCKHqGT9lWCmKz5AnfwLOtwwj4c Er1287gU5yBYS4nlMe3NluCuWTzJ/AZ2P7mO0GZxMQyFOECGMErUS1/BSnoSbhMolK vPx5WXywuwRLwGOeGyljUmZ5NMpN7X0Up3ozMJIR+OJlydOIqhJU0bUv/Pcy1QHkG7 3y5KpMRswXzsjB+YsoD0hCYs1aV8iqyJFacG92VrIfEBglV01004PdORtR/zRX+OO+ T0fZFQ5+LytAuWP9fGNKRZkM0f0z48SYkKv3WSDpDt/CadcnlqAI3WHSzBPjp4FBGl 13jCMj/OWlpQg== From: Michael Ellerman To: Christophe Leroy , "linuxppc-dev@lists.ozlabs.org" Cc: "mike.kravetz@oracle.com" , "linux-mm@kvack.org" , "aneesh.kumar@linux.ibm.com" Subject: Re: [PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf() In-Reply-To: <4c607d70-6b1e-46d1-72f2-8bbf0fc40949@csgroup.eu> References: <20220903123640.719846-1-mpe@ellerman.id.au> <20220903123640.719846-2-mpe@ellerman.id.au> <4c607d70-6b1e-46d1-72f2-8bbf0fc40949@csgroup.eu> Date: Sun, 04 Sep 2022 21:32:39 +1000 Message-ID: <87leqztlwo.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662291163; a=rsa-sha256; cv=none; b=2Ivkxw1PgvM67CtkRME5J9zqED+0mAkCwBkoskpGY+23ykCdKGxF712d/7NMyakbhNtuIb T6pYCAWmAaIBwZy1/Cc/3S0FY3EY/tmfkDNe6preMCpclzSC7JUG0FyT/nT+CrUieSM4aV Tw0Tt7bxb23Gr3RYJ9vYLH3zVm99ECo= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=ellerman.id.au header.s=201909 header.b=QnNmWbRC; spf=pass (imf03.hostedemail.com: domain of mpe@ellerman.id.au designates 150.107.74.76 as permitted sender) smtp.mailfrom=mpe@ellerman.id.au; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662291163; 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=mLGcxzbnnbxu6EKrXGdhCH+nPAYj+1VHsPHafBchnyw=; b=2GMLQhVNo3Cddr8kUuA/0kGKpH755PsWsAt+6z9vxCDsbYU6BdBjNSPy+LjM6kTaj7RGCz pNk5qq3ADsij5SMOqDwhjCAKdYNvlqM2L/fG2epzHomxr13C71NX0mbEWyhEcG1rdz2yLI KBhaImwTAY4FV7CCo8Z+QAEIpWbvfnw= X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=ellerman.id.au header.s=201909 header.b=QnNmWbRC; spf=pass (imf03.hostedemail.com: domain of mpe@ellerman.id.au designates 150.107.74.76 as permitted sender) smtp.mailfrom=mpe@ellerman.id.au; dmarc=none X-Rspamd-Server: rspam09 X-Stat-Signature: ps5yxocr8auexc31kjw6q1x4crj81psm X-Rspamd-Queue-Id: 3E53E2005F X-HE-Tag: 1662291163-312826 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: Christophe Leroy writes: > Le 03/09/2022 =C3=A0 14:36, Michael Ellerman a =C3=A9crit=C2=A0: >> Because 64-bit Book3S uses pgtable-nop4d.h, the P4D is folded into the >> PGD. So P4D entries are actually PGD entries, or vice versa. >>=20 >> The other way to think of it is that the P4D is a single entry page >> table below the PGD. Zero bits of the address are needed to index into >> the P4D, therefore a P4D entry maps the same size address space as a PGD >> entry. >>=20 >> As explained in the previous commit, there are no huge page sizes >> supported directly at the PGD level on 64-bit Book3S, so there are also >> no huge page sizes supported at the P4D level. >>=20 >> Therefore p4d_is_leaf() can never be true, so drop the definition and >> fallback to the default implementation that always returns false. > > Then here as well, you are removing the only architecture which=20 > implements a non 'always false' version of p4d_leaf(). > > x86 has on that is always false: > > #define p4d_leaf p4d_large > static inline int p4d_large(p4d_t p4d) > { > /* No 512 GiB pages yet */ > return 0; > } > > So, should it be dropped as well and all uses removed from core mm ? Probably? I see very few uses of p4d_leaf(), so I suspect it's not actually being called in all the places it should be if it ever returned true. See eg. follow_p4d_mask() which doesn't call it. I think it would be best to remove it and if anyone ever implements huge pages at that level (unlikely?) they will need to go back and add support in the right places. But ultimately it's up to the mm folks to decide IMHO. cheers 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C19E6ECAAD3 for ; Sun, 4 Sep 2022 11:33:16 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4ML8fL52c1z3bkG for ; Sun, 4 Sep 2022 21:33:14 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ellerman.id.au header.i=@ellerman.id.au header.a=rsa-sha256 header.s=201909 header.b=QnNmWbRC; dkim-atps=neutral Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4ML8dh3l9kz2xJL for ; Sun, 4 Sep 2022 21:32:40 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ellerman.id.au header.i=@ellerman.id.au header.a=rsa-sha256 header.s=201909 header.b=QnNmWbRC; dkim-atps=neutral Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4ML8dh0h9pz4xD3; Sun, 4 Sep 2022 21:32:40 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1662291160; bh=mLGcxzbnnbxu6EKrXGdhCH+nPAYj+1VHsPHafBchnyw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QnNmWbRCa0lnHBgLJ47GutZ6jrIQhZ1hDyo8cLtCKHqGT9lWCmKz5AnfwLOtwwj4c Er1287gU5yBYS4nlMe3NluCuWTzJ/AZ2P7mO0GZxMQyFOECGMErUS1/BSnoSbhMolK vPx5WXywuwRLwGOeGyljUmZ5NMpN7X0Up3ozMJIR+OJlydOIqhJU0bUv/Pcy1QHkG7 3y5KpMRswXzsjB+YsoD0hCYs1aV8iqyJFacG92VrIfEBglV01004PdORtR/zRX+OO+ T0fZFQ5+LytAuWP9fGNKRZkM0f0z48SYkKv3WSDpDt/CadcnlqAI3WHSzBPjp4FBGl 13jCMj/OWlpQg== From: Michael Ellerman To: Christophe Leroy , "linuxppc-dev@lists.ozlabs.org" Subject: Re: [PATCH 2/2] powerpc/mm/64s: Drop p4d_leaf() In-Reply-To: <4c607d70-6b1e-46d1-72f2-8bbf0fc40949@csgroup.eu> References: <20220903123640.719846-1-mpe@ellerman.id.au> <20220903123640.719846-2-mpe@ellerman.id.au> <4c607d70-6b1e-46d1-72f2-8bbf0fc40949@csgroup.eu> Date: Sun, 04 Sep 2022 21:32:39 +1000 Message-ID: <87leqztlwo.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "linux-mm@kvack.org" , "aneesh.kumar@linux.ibm.com" , "mike.kravetz@oracle.com" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Christophe Leroy writes: > Le 03/09/2022 =C3=A0 14:36, Michael Ellerman a =C3=A9crit=C2=A0: >> Because 64-bit Book3S uses pgtable-nop4d.h, the P4D is folded into the >> PGD. So P4D entries are actually PGD entries, or vice versa. >>=20 >> The other way to think of it is that the P4D is a single entry page >> table below the PGD. Zero bits of the address are needed to index into >> the P4D, therefore a P4D entry maps the same size address space as a PGD >> entry. >>=20 >> As explained in the previous commit, there are no huge page sizes >> supported directly at the PGD level on 64-bit Book3S, so there are also >> no huge page sizes supported at the P4D level. >>=20 >> Therefore p4d_is_leaf() can never be true, so drop the definition and >> fallback to the default implementation that always returns false. > > Then here as well, you are removing the only architecture which=20 > implements a non 'always false' version of p4d_leaf(). > > x86 has on that is always false: > > #define p4d_leaf p4d_large > static inline int p4d_large(p4d_t p4d) > { > /* No 512 GiB pages yet */ > return 0; > } > > So, should it be dropped as well and all uses removed from core mm ? Probably? I see very few uses of p4d_leaf(), so I suspect it's not actually being called in all the places it should be if it ever returned true. See eg. follow_p4d_mask() which doesn't call it. I think it would be best to remove it and if anyone ever implements huge pages at that level (unlikely?) they will need to go back and add support in the right places. But ultimately it's up to the mm folks to decide IMHO. cheers