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 40423C25B76 for ; Tue, 11 Jun 2024 09:34:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD79F6B008C; Tue, 11 Jun 2024 05:34:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A87D36B0095; Tue, 11 Jun 2024 05:34:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 901816B0096; Tue, 11 Jun 2024 05:34:30 -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 72EFC6B008C for ; Tue, 11 Jun 2024 05:34:30 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0B19681264 for ; Tue, 11 Jun 2024 09:34:30 +0000 (UTC) X-FDA: 82218097500.08.D63AFEA Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf05.hostedemail.com (Postfix) with ESMTP id D0FEC10001A for ; Tue, 11 Jun 2024 09:34:26 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=1h9kfKoU; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Wyti0idM; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=1h9kfKoU; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Wyti0idM; spf=pass (imf05.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718098467; 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=bXl9G+kh6CJWJjfSYdY3mI/mE/xXvq102BbFQ15gmgk=; b=NYUjOziDrLAXjOrdB/KXTYy7SAe1IIITWK2+rD8tI5Tiw2mmyKdyJ3T7PmSV55tmdjgnHx Zky3MlE78QsilZjFLzRtiWpCSIwo9Tsccw2f9y0WKbalmLqoTEgxb88sBNF5NPnX/VYOP6 kO2KXhn06dd1xenYyuUjQZbp1ZG7jQw= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=1h9kfKoU; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Wyti0idM; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=1h9kfKoU; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=Wyti0idM; spf=pass (imf05.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718098467; a=rsa-sha256; cv=none; b=bFFc5sZ6w3ueQTdAwPWPxiVJiN3cLYQLzjlbnvculGgvsQr2zAk1iIIeNwB2skA0f5zlSO kBKPDpC5WAHr3ZSBc35FuiCq3pULeYmx33p05d/CHOUb5npUJUCFmLki7SrHFHeRKYiiAD QR3/LVMtaXbqU4bhe7mhiEUqxnIRh1M= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 2FB9133686; Tue, 11 Jun 2024 09:34:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1718098465; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bXl9G+kh6CJWJjfSYdY3mI/mE/xXvq102BbFQ15gmgk=; b=1h9kfKoUjzUX7Pg0FYO4/Hn86ca25G+Dw0AJG6LeaEH4SJ+Pr27qT5mX6xNgxC6+O6nlft br7k3/K0BFcSDett6c63kGZre4r1PJdSH5PsMsFXqyiITD7SPqMSS1uvPAn4oCFafdgeLW Px/kUM1cWdNYU4YVxTTrQ2a7A0yPIFM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1718098465; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bXl9G+kh6CJWJjfSYdY3mI/mE/xXvq102BbFQ15gmgk=; b=Wyti0idMR4rKs3LoThTM+Y8V0nVad7j2jppVkPhnwFxzg/7HdB6YPRlKnU0DR4KISNMvTk 44kaEKvNEVIr0MBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1718098465; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bXl9G+kh6CJWJjfSYdY3mI/mE/xXvq102BbFQ15gmgk=; b=1h9kfKoUjzUX7Pg0FYO4/Hn86ca25G+Dw0AJG6LeaEH4SJ+Pr27qT5mX6xNgxC6+O6nlft br7k3/K0BFcSDett6c63kGZre4r1PJdSH5PsMsFXqyiITD7SPqMSS1uvPAn4oCFafdgeLW Px/kUM1cWdNYU4YVxTTrQ2a7A0yPIFM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1718098465; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bXl9G+kh6CJWJjfSYdY3mI/mE/xXvq102BbFQ15gmgk=; b=Wyti0idMR4rKs3LoThTM+Y8V0nVad7j2jppVkPhnwFxzg/7HdB6YPRlKnU0DR4KISNMvTk 44kaEKvNEVIr0MBQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id A858413A55; Tue, 11 Jun 2024 09:34:24 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id Jbt2JiAaaGapdAAAD6G6ig (envelope-from ); Tue, 11 Jun 2024 09:34:24 +0000 Date: Tue, 11 Jun 2024 11:34:23 +0200 From: Oscar Salvador 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: [PATCH v5 02/18] mm: Define __pte_leaf_size() to also take a PMD entry Message-ID: References: <172b11c93e0de7a84937af2da9f80bd17c56b8c9.1717955558.git.christophe.leroy@csgroup.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <172b11c93e0de7a84937af2da9f80bd17c56b8c9.1717955558.git.christophe.leroy@csgroup.eu> X-Rspamd-Queue-Id: D0FEC10001A X-Rspam-User: X-Rspamd-Server: rspam09 X-Stat-Signature: qdb4nhbtjz7qg7tsqnbqtexgg15rrqzh X-HE-Tag: 1718098466-893311 X-HE-Meta: U2FsdGVkX1+hVNleWcBBmw2R9D4NXwCcYuLomc0gO1kCzAP4EwRNjo+k8YkyIP6u9sQas2KDlqYTJosj3kSPL5GefLgccoWOm+hIG22dtlOgwlHGiJkumnDP3CWN04j1w3Pc8hNxPV+DEflKS8I2Hyul9yd+evZ0T66LLIZzuKBTJkNlp1Mkvcz57Y3CWlhPS3iIJnh8IsQ5Ke/M9+PSFRy5srnU9hwTkcVDPwQXfVR9JcKPiENWI841eL1bN9CmOpF+LbRHC5Fn29VYXMpyEq3hjN+9cu6U8mlZl2gRW/6x9EUwoKEkdsgs/MwFZmnAP2BxKDwpx6V7lM4P+LTSFjGAnVThdOm+131fAn6SvD2mSGG41vZ9/t04ql7tckCg3EYaZaigDE3Nug1W0B82n7pbTs2Uw1wehpqwj834slWg0/dDIKGuAt6/y6qc3skvYKvXQVEu1OqMhos+P2sWQ9iQR2uBN25V2MiBtKvgTv8dADrJjwIKX24GEfA6/Sz24ZoH7ArmahCkwYK2EwyJ6Th11GE0vhk1WzTNHdf8nmuGtChZojoNJxQYd96qyYiXzUnKAYlV7kRgHX2IbemGlf01UamC3Wl3ykbrDe4eubjB3ghqMgTy1VDUJc6o6XXTEzsXQb+pBcg2ltMRE8jGkv9vFKIjFFbAZarBb6js5Xlug6r/g/qiXZHpMeFJruokCAHomkkMPChEE06n+ClV1oyMMosEw8FrhxPx735/EjA7gEsQ9qVhM2e1TM/eJw6IqcwtEGFPPO9NacFJGk15mf8ZJPl46f30SbDHcqb9omKzyFsgLwe/T+S6dqCEvXYabBHQscB4id3iZdQx0JRkM7CVJUeUf6leKXSVHNvsE26f7D3OuboNj5Z5CTrrWpKEx+DSxnpKMNGV5EGUmtwIXXzWkjABQG1dEHgYATtPjVkjs7iW3S6+y0WRj2cUtW6GRu7bedR+ZfppwXTZqYh Be9cEX92 IOFk/ix192nmvxZeXjHhYVJn9d8Ya9mC0+0mJKiP8q0UZlxWhveRuZjmxuIiMsibPVYqXMlpgnuLrgWbIkZtTmGjB8ydaE4/YmJkMheXXCS/rT1qqlX4Do6yK9CpsG/JlUA9BXWtVudscBBZnJ3pzHEGW3clPF93v6Brci6SC/bT+69GVy6mceROtsbTE+wt5YHa5ToFKQaM/nrRmxrz0yzz4JvqgNpGcL2knHsWCNhqtt7QQNl8rwotnGlaTlZyANAvmDHVjNZHjUHwx+5tziXRhCw== 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, Jun 10, 2024 at 07:54:47AM +0200, Christophe Leroy wrote: > On powerpc 8xx, when a page is 8M size, the information is in the PMD > entry. So allow architectures to provide __pte_leaf_size() instead of > pte_leaf_size() and provide the PMD entry to that function. > > When __pte_leaf_size() is not defined, define it as a pte_leaf_size() > so that architectures not interested in the PMD arguments are not > impacted. > > Only define a default pte_leaf_size() when __pte_leaf_size() is not > defined to make sure nobody adds new calls to pte_leaf_size() in the > core. Hi Christophe, Now I am going to give you a hard time, so sorry in advance. I should have raised this before, but I was not fully aware of it. There is an ongoing effort of unifying pagewalkers [1], so hugetlb does not have to be special-cased anymore, and the operations we do for THP on page-table basis work for hugetlb as well. The most special bit about this is huge_ptep_get. huge_ptep_get() gets special handled on arm/arm64/riscv and s390. arm64 and riscv is about cont-pmd/pte and propagate the dirty/young bits bits, so that is fine as walkers can already understand that. s390 is a funny one because it converts pud/pmd to pte and viceversa, because hugetlb *works* with ptes, so before returning the pte it has to transfer all bits from PUD/PMD level into a something that PTE level can understand. As you can imagine, this can be gone as we already have all the information in PUD/PMD and that is all pagewalkers need. But we are left with the one you will introduce in patch#8. 8MB pages get mapped as cont-pte, but all the information is stored in the PMD entries (size, dirtiness, present etc). huge_ptep_get() will return the PMD for 8MB, and so all operations hugetlb code performs with what huge_ptep_get returns will be performed on those PMDs. Which brings me to this point: I do not think __pte_leaf_size is needed. AFAICS, it should be enough to define pmd_leaf on 8xx, and return 8MB if it is a 8MB hugepage. #define pmd_leaf pmd_leaf static inline bool pmd_leaf(pmd_t pmd) { return pmd_val(pmd) & _PMD_PAGE_8M); } and then pmd_leaf_size to return _PMD_PAGE_8M. This will help because on the ongoing effort of unifying hugetlb and getting rid of huge_ptep_get() [1], pagewalkers will stumble upon the 8mb-PMD as they do for regular PMDs. Which means that they would be caught in the following code: ptl = pmd_huge_lock(pmd, vma); if (ptl) { - 8MB hugepages will be handled here smaps_pmd_entry(pmd, addr, walk); spin_unlock(ptl); } /* pte stuff */ ... where pmd_huge_lock is: static inline spinlock_t *pmd_huge_lock(pmd_t *pmd, struct vm_area_struct *vma) { spinlock_t *ptl = pmd_lock(vma->vm_mm, pmd); if (pmd_leaf(*pmd) || pmd_devmap(*pmd)) return ptl; spin_unlock(ptl); return NULL; } So, since pmd_leaf() will return true for 8MB hugepages, we are fine, because anyway we want to perform pagetable operations on *that* PMD and not the ptes that are cont-mapped, which is different for e.g: 512K hugepages, where we perform it on pte level. So I would suggest that instead of this patch, we have one implementing pmd_leaf and pmd_leaf_size for 8Mb hugepages on power8xx, as that takes us closer to our goal of unifying hugetlb. [1] https://github.com/leberus/linux/tree/hugetlb-pagewalk-v2 -- Oscar Salvador SUSE Labs