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 2EB0DC3600C for ; Thu, 3 Apr 2025 20:47:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 30F22280004; Thu, 3 Apr 2025 16:47:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 29766280001; Thu, 3 Apr 2025 16:47:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 15E4D280004; Thu, 3 Apr 2025 16:47:19 -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 E6C94280001 for ; Thu, 3 Apr 2025 16:47:18 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 05ABA81158 for ; Thu, 3 Apr 2025 20:47:20 +0000 (UTC) X-FDA: 83293917840.28.664331A Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf23.hostedemail.com (Postfix) with ESMTP id 52DF0140004 for ; Thu, 3 Apr 2025 20:47:18 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of cmarinas@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743713238; 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; bh=/quf11TP5DQgl9OoNlHgCgBQHgJEF0iW7Gqz5VJqgoY=; b=8ioCJ/fmfx0zbxBsMJ6uhsAwYDHQH31NvpYhM6xPIu0Eyo5F6yuOPjjuBG2VLWEvH90Vq9 mvzlcljPAejHkzzJ92qKn5co5OF1N3f4EBveQJceuAFl+sLfLVjMX5gGuM6B663V1zOmoS Ys6JI29Clgy2rKEG1YinLq44X9FgENk= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=none; spf=pass (imf23.hostedemail.com: domain of cmarinas@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743713238; a=rsa-sha256; cv=none; b=lEEQiFppF+RLQfIOzcwDF+KKEhqf9L1y3UW+3jVuSCDfOdPQ0LKBDM+tIsClh/fwQIMpEQ nB2WqubjIhykcAes0hBSF0YD3KyNQsApRzIlJmwISDiOYJn3SKzQmR2TEDSYTwZAP/wE83 ig4mTTRGkGwsT7B3zo/BE6/oPAvG3pA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 7ABF3445BD; Thu, 3 Apr 2025 20:47:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94C91C4CEE3; Thu, 3 Apr 2025 20:47:13 +0000 (UTC) Date: Thu, 3 Apr 2025 21:47:10 +0100 From: Catalin Marinas To: Ryan Roberts Cc: Will Deacon , Pasha Tatashin , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , David Hildenbrand , "Matthew Wilcox (Oracle)" , Mark Rutland , Anshuman Khandual , Alexandre Ghiti , Kevin Brodsky , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 02/11] arm64: hugetlb: Refine tlb maintenance scope Message-ID: References: <20250304150444.3788920-1-ryan.roberts@arm.com> <20250304150444.3788920-3-ryan.roberts@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250304150444.3788920-3-ryan.roberts@arm.com> X-Rspamd-Queue-Id: 52DF0140004 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: wmgxhk5xfjfxbq9w3skmmo3q3d4czynz X-HE-Tag: 1743713238-982448 X-HE-Meta: U2FsdGVkX1/M6qSTohju3SmpWZVKdfiRafIeFZlnkyM2AR6QmmpbdGU1MhquLDxOQ0hU4Db/rTxqwoW8jhvJXrpvYFSIV80G7AamvCB76Dn+/cyqfK1Yk+7+DQpoWneRC2VJXPUL+ogQk2qcfTq2Ikq48byNrTQefDA9lS2ljNr4DTNBlszfDOjCedet/XdkCtMmrgeCpLVB2E9FaqTwfUGKH+SolvxBBTb3T4lE0//i1nuUOYonjAg+m8t92xFeLSa29BtdNm9er6FxCsKkm5ns2ejh6kV965hNfV5Z/gUMrS+sFVVMNn6QDYneVO7ovqbwOnvZeOZQt0IXu638JFGe2RF9Vh/ISjokLp/6Rbh7qI9qSbEAbY/Qj7LpUjLt9GmuUGb14Vm3EpzLAVp0CWY0aBT/jBvyaYuU4CViKabGbGiGQNWf6ydtYod2UTd6CYCETRjfwBtAjOrcut5H9DtzJ1G1W3r9KXcFd1yn82rxsNjR7eK1ZKLFPSpoRZg65DXrX9JuDSHT8FOjiPNLE2rctOjz0VURQkmT1VaPTlt7I41RjuzNk7xlo5UTg2VpHeJ7a/p/DyfgekuiZeBOIjZJnJjUxrDt0pn+n5xlQOlTMZOTgIOQyx0egcjfP3BVtamaVZZN0S0kqa7FJb+L6okNHovY/E64lZjuxwbUWHXdJ2HegNjrVyJfTpDdlCbN3zHR67gmNMnULAdgaNtLAKGFNmyqhFc+MbSzCuX4SoFHUxH79RAtBjzmeXNv8lWdh0vmjEdtvcpAZ3sJi9AqMxWNMJS9clVw5tMQ8Nbo86YRE6ynFzFCpJER+mI0cd7ZtdArkRW1aEZewY5Wq3kMkGJb+Mqg5cSBVVOM4OGcZLjQCgJWa83bPo93EAtD0H1z4dYjKnsWbZJ6ml+LjKO+i1R91WOPLLz8qz8kjfYwb05G6ppSef7Bmt0q0fwxc2LFzh26UuPH3dAq4CuvxY+ vxUXSS0a PaLSZia0An//Jv7OlQNexacTzEd3KviD9En2X+ZQfnwHGBoBi8ud2ByQXwiHp2Hx/IPuXad9pGh2XSoa1IN7zPS39NthGDPKeXYXv7zmXExUbIWFKEFuIiBQ5OyTuFLSjh6BMzK9xiouuF8vTes5VsTW/rl65LdqlG2IXm5lahTtc6C8ixFxOI57uFOmwlr6XeTKcAc8E9XTC+PmWuEfsA64zAwoMFrCmIX0kB0Q1r6/IIQyAO523UalKK+KU0mFIxJ6s5JN7Uw4GfmJBrQyuIS6OOGDH0u9jGzToMINADX4+sB8hU8vt9REqMFdK6QGaipM1la+7xCsqpCWu6TcCtG4UWQLPeEryP3TIJ3jIClgUeZlEDVzJkVTmFNnWXiuVI1hQlkn409GPM2Kbi7kunsf5wg== 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, Mar 04, 2025 at 03:04:32PM +0000, Ryan Roberts wrote: > When operating on contiguous blocks of ptes (or pmds) for some hugetlb > sizes, we must honour break-before-make requirements and clear down the > block to invalid state in the pgtable then invalidate the relevant tlb > entries before making the pgtable entries valid again. > > However, the tlb maintenance is currently always done assuming the worst > case stride (PAGE_SIZE), last_level (false) and tlb_level > (TLBI_TTL_UNKNOWN). We can do much better with the hinting; In reality, > we know the stride from the huge_pte pgsize, we are always operating > only on the last level, and we always know the tlb_level, again based on > pgsize. So let's start providing these hints. > > Additionally, avoid tlb maintenace in set_huge_pte_at(). > Break-before-make is only required if we are transitioning the > contiguous pte block from valid -> valid. So let's elide the > clear-and-flush ("break") if the pte range was previously invalid. > > Signed-off-by: Ryan Roberts Reviewed-by: Catalin Marinas