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 13CB5C27C4F for ; Thu, 13 Jun 2024 07:20:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 84EAE6B009E; Thu, 13 Jun 2024 03:20:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7FECA6B009F; Thu, 13 Jun 2024 03:20:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69F2E6B00A0; Thu, 13 Jun 2024 03:20:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4CFC16B009E for ; Thu, 13 Jun 2024 03:20:02 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C35AF1C1DD9 for ; Thu, 13 Jun 2024 07:20:01 +0000 (UTC) X-FDA: 82225016202.01.1DA5011 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf12.hostedemail.com (Postfix) with ESMTP id 7EA8B40009 for ; Thu, 13 Jun 2024 07:19:59 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=l8ViJ5DV; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=fVMKfSb4; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=l8ViJ5DV; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=fVMKfSb4; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf12.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718263198; a=rsa-sha256; cv=none; b=vHsA/cbSnxyotgQ37T765whJFOi+WrRVcFVoEZcLYz/1rK3+33c00Nd5B6gzSIyL2j4NUF ZjDtrFSIvlIAJkUQeCJC0DLxFc6LEimT9uvlNOXNJKiLDmf1e4fo75oCAdc4C6PTBKK02c yTR5MfKP9JC8mN+NQA3OwqQ4GgtHyFM= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=l8ViJ5DV; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=fVMKfSb4; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=l8ViJ5DV; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=fVMKfSb4; dmarc=pass (policy=none) header.from=suse.de; spf=pass (imf12.hostedemail.com: domain of osalvador@suse.de designates 195.135.223.130 as permitted sender) smtp.mailfrom=osalvador@suse.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718263198; 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=5vB0B07P2+DuuejZFzMWZoJyc2y0Vfw/uEPye59MNaU=; b=wpIWdGqDpOtK2Rj/N+jI6VvpIczkaCIhf1H5ojNTPdnfO19Oq5ybsX6pBPB/O9Y948bbFX Eu3S0crfbM0WwzNVT/BqiRa/QmyreQ6biKe2gYVW/YtFDEHNOuNMiPGGBSjqSSppxw1UGP HomKsyt/z4BhES6AJTdFRwEKng8qT6s= 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 CBDC935011; Thu, 13 Jun 2024 07:19:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1718263197; 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=5vB0B07P2+DuuejZFzMWZoJyc2y0Vfw/uEPye59MNaU=; b=l8ViJ5DVLW76yFotFw/cV8vahWRyrO809JHirtZtZjLyvf+LSR6DbA2dHv8z2/z1huiRPU HvQWqCdlTxVe7eHURYrkU+Mxt8L7Zd9GTvMnXesBJgqxvhzG3f6yl/hd1yYEoJr+Yd8ntn LLg7Le3IOok3oDEhZwOwYPgnrHfqbGI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1718263197; 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=5vB0B07P2+DuuejZFzMWZoJyc2y0Vfw/uEPye59MNaU=; b=fVMKfSb4JEVOhWLp/vpZlVLX1FT0spQlCukyyxI+ZmXsvlZnkaxBwhwsBTtKQCmT4voltA 5A0oY84OFL7IxWDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1718263197; 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=5vB0B07P2+DuuejZFzMWZoJyc2y0Vfw/uEPye59MNaU=; b=l8ViJ5DVLW76yFotFw/cV8vahWRyrO809JHirtZtZjLyvf+LSR6DbA2dHv8z2/z1huiRPU HvQWqCdlTxVe7eHURYrkU+Mxt8L7Zd9GTvMnXesBJgqxvhzG3f6yl/hd1yYEoJr+Yd8ntn LLg7Le3IOok3oDEhZwOwYPgnrHfqbGI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1718263197; 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=5vB0B07P2+DuuejZFzMWZoJyc2y0Vfw/uEPye59MNaU=; b=fVMKfSb4JEVOhWLp/vpZlVLX1FT0spQlCukyyxI+ZmXsvlZnkaxBwhwsBTtKQCmT4voltA 5A0oY84OFL7IxWDw== 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 4EF4513A87; Thu, 13 Jun 2024 07:19:57 +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 BzZwEJ2damYySAAAD6G6ig (envelope-from ); Thu, 13 Jun 2024 07:19:57 +0000 Date: Thu, 13 Jun 2024 09:19:51 +0200 From: Oscar Salvador To: LEROY Christophe Cc: Peter Xu , Andrew Morton , Jason Gunthorpe , 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: X-Rspamd-Queue-Id: 7EA8B40009 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ayh8j7hy8pqtqoxf6beuq9mg1jx7b1dm X-HE-Tag: 1718263199-46056 X-HE-Meta: U2FsdGVkX1/av54AI5NDdbvVqhwMcuA5xGQwg1iq91n3niZQ5KZOInAbBALqw04e8tCRSzjJdu8RxQ+a4odMrqs8jlpMyta4AvtXUCySoAHxFwS6zvXryxk4boq0djbL97WTP/2GESFlEG5onL9ZtWKUW4g0epkNNYL3JeIjPCdp4rllhxxmdYUVnWUz65oXyixEbgX62ZjTgK+LqwGDaHNRvPbAHRi3TFnxCneMouW4FmhMxQfXUkxvxsULzZGS/KSsmmjIXRkVS6xpRSF5H/WPR0CJxjDVuEFakSyjFvt3lnfzFcUgCuik2PCmJkLibPW1qJwkluqGHeUSMbAlRS+6Nn4EdPWoloxbO4YkTu7Hc4UR+zwk/R9HjpztKhw+IhQ9kWP845eg2mvxxvD7KBP1nK1C1g3w6iRtjkpEj7+qDAG+3n96EabWyRGLfUZLLJmu0d/6pbY/C4FlbG+aE3jRp5MXSHXZttinxxQz8nL1YwvfacbUDbFiUfsoJyRC7g/Bu7urLs/NndKochbLuzKFaXs8Nq2KygaQ6w/ZOVp2dEwDC+SrQ2fFLm9eVs7MchRQ2g8RJoAfw+K2mJtkp8tM2W8nM53VPBq5BlEAFHhQ882e6U5P0KiA5c9p6v8r6kaClnuvWZqrFMirFngrAgzOTWoj1ZNt6BR9Xr7nxYcRKTE7WPc23VH/jhgnnH3XJgunv5juTRwtFDuhSRjHBhFgjeDq0Yl6SHUt4lH2Lv4z7v66SpDPSmkx+ivUqsrQI2OHN6GJC2V6yPvxnaV1fkPKrTmBr4TguVMipZXnVUDBxmH2wAz0zkiNp94tZgTeDv0eUokV5NmWkJzIhDKBxkORX4g46x05O9DRBEbYbWB2M8Qt5v6BTzukPYs/I8vAjB7qaqB6uQ6YMrVxooDwFkCMSBnptr2FezTAtLmgQ6Rc2yD4pD4QKCYhZz11cP7LtEByPHTO0D2Xcj2rfkf 9qGZA8vw uqkttlsUJ86snNUULwDlcXQJLKANqA7WXB9h7nWewLuGrjC3kpcSSVtfpfz2OYg3KdvF3Yn5qMaFAwzrPs5Rg2RG5XQo3N6QzwhHwEsXz6PrCeDvUheUIL9RvkZoY3qVsXqtM2cocQQTGoM2u3FS0Nm75sFNCzUqUeshugYFFhxoOx+Fd2sMmp02Me3nSrj3FnK/WcHv8hdSnauINLRt5ib2WEjo9F4IeuCj00xUQyTc5sHXt61D2IbD6UyQnSrs2P57PegTE53Juh/glg/Pmj6qS43m7y3IL4UapWLLjnXOHVIlofHbqzihfUH5yMGVZl949cgrkKXYoVV0= 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 Tue, Jun 11, 2024 at 07:00:14PM +0000, LEROY Christophe wrote: > We have space available in PMD if we need more flags, but in PTE I can't > see anything possible without additional churn that would require > additional instructions in TLB miss handlers, which is what I want to > avoid most. > > Bits mapped to HW PTE: > > #define _PAGE_PRESENT 0x0001 /* V: Page is valid */ > #define _PAGE_NO_CACHE 0x0002 /* CI: cache inhibit */ > #define _PAGE_SH 0x0004 /* SH: No ASID (context) compare */ > #define _PAGE_SPS 0x0008 /* SPS: Small Page Size (1 if 16k, 512k or 8M)*/ > #define _PAGE_DIRTY 0x0100 /* C: page changed */ > #define _PAGE_NA 0x0200 /* Supervisor NA, User no access */ > #define _PAGE_RO 0x0600 /* Supervisor RO, User no access */ > > SW bits masked out in TLB miss handler: > > #define _PAGE_GUARDED 0x0010 /* Copied to L1 G entry in DTLB */ > #define _PAGE_ACCESSED 0x0020 /* Copied to L1 APG 1 entry in I/DTLB */ > #define _PAGE_EXEC 0x0040 /* Copied to PP (bit 21) in ITLB */ > #define _PAGE_SPECIAL 0x0080 /* SW entry */ > #define _PAGE_HUGE 0x0800 /* Copied to L1 PS bit 29 */ > > All bits are used. The only thing would could do but that would have a > performance cost is to retrieve _PAGE_SH from the PMD and use that bit > for something else. I guess that this would be the last resort if we run out of options. But at least it is good to know that there is a plan B (or Z if you will :-)) > But I was maybe thinking another way. Lets take the exemple of > pmd_write() helper: > > #define pmd_write(pmd) pte_write(pmd_pte(pmd)) > > At the time being we have > > static inline pte_t pmd_pte(pmd_t pmd) > { > return __pte(pmd_val(pmd)); > } > > But what about something like > > static inline pte_t pmd_pte(pmd_t pmd) > { > return *(pte_t *)pmd_page_vaddr(pmd); > } I think this could work, yes. So, we should define all pmd_*(pmd) operations for 8xx the way they are defined in include/asm/book3s/64/pgtable.h. Other page size would not interfere because they already can perform operations on pte level. Ok, I think we might have a shot here. I would help testing, but I do not have 8xx hardware, and Qemu does not support 8xx emulation, but I think that if we are careful enough, this can work. Actually, as a smoketest would be enough to have a task with a 8MB huge mapped, and then do: static const struct mm_walk_ops test_walk_ops = { .pmd_entry = test_8mbp_hugepage, .pte_entry = test_16k_and_512k_hugepage, .hugetlb_entry = check_hugetlb_entry, .walk_lock = PGWALK_RDLOCK, }; static int test(void) { pr_info("%s: %s [0 - %lx]\n", __func__, current->comm, TASK_SIZE); mmap_read_lock(current->mm); ret = walk_page_range(current->mm, 0, TASK_SIZE, &test_walk_ops, NULL); mmap_read_unlock(current->mm); pr_info("%s: %s ret: %d\n", __func__, current->comm, ret); return 0; } This is an extract of a debugging mechanism I have to check that I am not going off rails when unifying hugetlb and normal walkers. test_8mbp_hugepage() could so some checks with pmd_ operations, print the results, and then compare them with those that check_hugetlb_entry() would give us. If everything is alright, both results should be the same. I can write the tests up, so we run some sort of smoketests. So yes, I do think that this is a good initiative. Thanks a lot Christoph -- Oscar Salvador SUSE Labs