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 B259FE77188 for ; Fri, 10 Jan 2025 19:18:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 40F218D0005; Fri, 10 Jan 2025 14:18:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A1D78D0001; Fri, 10 Jan 2025 14:18:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E9BC8D0005; Fri, 10 Jan 2025 14:18:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id F0AD38D0001 for ; Fri, 10 Jan 2025 14:18:37 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A1711140C80 for ; Fri, 10 Jan 2025 19:18:37 +0000 (UTC) X-FDA: 82992503874.03.3EF0371 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf18.hostedemail.com (Postfix) with ESMTP id E1C7C1C000D for ; Fri, 10 Jan 2025 19:18:35 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lVSbNBfB; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of mcgrof@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mcgrof@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736536716; a=rsa-sha256; cv=none; b=g9sCqymiEtTvp+08UnZw44hqwmW5SvFP8Ilc4G+HlKmL0QfiqohPwTVhKB2EC62HXdQJ49 nLkNVZ71oknjolSiHg55HbfuZgDd7O/YbsS+Rtq0vt92Z1nKG3hldyaR9cHv8HTAsARQUu SVpcbZ1a5eLe1pbYC16EaIagqsvnraM= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lVSbNBfB; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of mcgrof@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mcgrof@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736536716; 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=MmNW7y3eqsd92Gzg8gEtV3OkdUAt4QIGvUyRb4/YY3Y=; b=muBNwZbwPcpcxfKwqczdwTpkwKY0buGJSTcgnW9rjThgm68K3iU5oT5GIftYgcaPs++Z3C qpnki43d54A1eGzzzlsrj/I56bLOHtSJx6R1wdFzYxnqUcX9lqF1mMLH/bK0zksXQjmwQg Yc4Akf9QQsTAkCxUbmM+LvmrPhu4A3U= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 8EF1EA4292D; Fri, 10 Jan 2025 19:16:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D2BDC4CED6; Fri, 10 Jan 2025 19:18:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736536714; bh=2qtn/yN8KGnvKM4Be6ymIMRepfChNk260BsIzmavFNU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lVSbNBfBgiPxfs3j9J4+Q/Mm+va0HnyJJvJ511BIZPHoPIheFgi517TCooWsbBMUd WSTmKdJWe1UfTSlATsW95ACeJ+2Ll0h4BtuuaSFwVIFk0Wv0zZu3LZGeJRFeQJn0qe lg2p9xQs3O5V2HOaVWmRlOJx02Yzw7s7vpvz4fokLmZ7ey61g0GQZuRvribH6nHyqr xDH3Wpe0L5t74rdpA5UINqI4Hxxsp6lB+b5KVRB/rten4cAybUcKdl/88Oc2pCe2TE 6b7kfjQEJbS5HJyWvsAtyyHoKwfXfP3N4KXgVgUwkJm645MDTdxDa3wPAeEVyf6U26 meOgl0uiogQDw== Date: Fri, 10 Jan 2025 11:18:32 -0800 From: Luis Chamberlain To: "Kirill A. Shutemov" Cc: Mike Rapoport , Andrew Morton , Andy Lutomirski , Anton Ivanov , Borislav Petkov , Brendan Higgins , Daniel Gomez , Daniel Thompson , Dave Hansen , David Gow , Douglas Anderson , Ingo Molnar , Jason Wessel , Jiri Kosina , Joe Lawrence , Johannes Berg , Josh Poimboeuf , "Kirill A. Shutemov" , Mark Rutland , Masami Hiramatsu , Miroslav Benes , "H. Peter Anvin" , Peter Zijlstra , Petr Mladek , Petr Pavlu , Rae Moar , Richard Weinberger , Sami Tolvanen , Shuah Khan , Song Liu , Steven Rostedt , Thomas Gleixner , kgdb-bugreport@lists.sourceforge.net, kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-um@lists.infradead.org, live-patching@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH 3/8] x86/mm/pat: Restore large pages after fragmentation Message-ID: References: <20241227072825.1288491-1-rppt@kernel.org> <20241227072825.1288491-4-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E1C7C1C000D X-Stat-Signature: s161c4czb7bf719dzczqxjjzgunw79yd X-Rspam-User: X-HE-Tag: 1736536715-685601 X-HE-Meta: U2FsdGVkX1+gl39Y4pBM7ZTFTcmWtbv6pxAm+IxSYpQ8DcnSnnJMabO13HlpaxBdpqtnk5yLLLquHi9bnN4Q9GKiRa2+R8rAM0AO/c9Uw9fG6IwnW0w9wFy+mh8AFvW2xPx/SxwqmrvvglAhPUeLYcCoH0ZgBjzchUdDmPKkX5wqsUIDCpSeauQUpnisuJvKk3PqNRL52CVZp7mZiDsKbcNolY42Rh2H6OeZOYM4KLbiSmpXfON4ivTgFM3hTkf8aWelV3oh3Px0c9JwsnkutkE5ffZDiFrR4NIWqLTh7tP8PEDVeJshemROjRpuAI9kt8GR1Y7wVSA6RO3ZNxLMWm55I1pCVR3XAmy/b6GJcOFTgqiGHVQz7IYONvmFECMmGNS+xz9vTCm3WyOXDCaQqDCWGuqZcC580GlB+OhtfVJY+FUD4CIYK9DQSEAYyz4tk9Tp9W6cX/YRfdPPDKHFXu8AkbIYysn7qKGdWWdT+VMKjnjjvi4EqhfhBwmZm6k6eeFvAjoM1b/rvfnJG78ylkzYzzh/PdhNcM8Z8v7015I9HVLimKG2U6LjDezuP/L977EIaETUoj/HE48HvBwftIl/V+i4TYe3tLSFJCY32uFuh63RDOaCDR7UB5z4yB/D95xaDscq5pIHEzC9Bkzaq7SC1Cj3wWDtek6SmkKQoW71KXMc30j6bVhRQ58+5QMw0fWVbhBVeQBpuepgt9h108dl2FXXDSabJyhZEifdaJiH38+Ky0W+DVsPBD8qL1M2lyyJZ4czsRsBcYso7IcfzIdZVPcC32ZKqKGvu+A/UDG5vK4c+O45sYw6Nn4wTsQ0a72W5GBoo3A2Xx6a7BR7qJ/c53VAb5rwIGOtgxbTCNwdezh5/zeGnqxQST6P/jgGgAiaipkF2UhRoa77y4lCNaIvCd3Ur1GzpCymXRjJghvS6IbAtXf7/fgXG2jCBpZAPiPz/XDBvg++e0zyeNc pLM7afWt Wb9zJR/THsIrDDya/1BXClHgvZdSJBErsmrRJbAWm20Dz/Zg+H6BhbgrwFdEM7RxJ/sae5hwJnsRiI/nUeZO68FA/JGngBriFCVaJcDv01yYsHcnFw695iO/kaZBPaLOY3B6VhLVI+cbzxNPvqRpyDWvuxsSDXzlAWqY8jD8i6Y2C/twdLH/O80/oZsDezxp3I1Sokloztq795DpJIQp333zRzaGG5szsP3Suv6HesCCwa3L2Gn/lmyEJ7sK8lwlDIba23YccTf9rMH3RcJwO54nNBOHZh4rcuoG5 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 Fri, Jan 10, 2025 at 12:36:59PM +0200, Kirill A. Shutemov wrote: > On Fri, Dec 27, 2024 at 09:28:20AM +0200, Mike Rapoport wrote: > > From: "Kirill A. Shutemov" > > > > Change of attributes of the pages may lead to fragmentation of direct > > mapping over time and performance degradation as result. > > > > With current code it's one way road: kernel tries to avoid splitting > > large pages, but it doesn't restore them back even if page attributes > > got compatible again. > > > > Any change to the mapping may potentially allow to restore large page. > > > > Hook up into cpa_flush() path to check if there's any pages to be > > recovered in PUD_SIZE range around pages we've just touched. > > > > CPUs don't like[1] to have to have TLB entries of different size for the > > same memory, but looks like it's okay as long as these entries have > > matching attributes[2]. Therefore it's critical to flush TLB before any > > following changes to the mapping. > > > > Note that we already allow for multiple TLB entries of different sizes > > for the same memory now in split_large_page() path. It's not a new > > situation. > > > > set_memory_4k() provides a way to use 4k pages on purpose. Kernel must > > not remap such pages as large. Re-use one of software PTE bits to > > indicate such pages. > > > > [1] See Erratum 383 of AMD Family 10h Processors > > [2] https://lore.kernel.org/linux-mm/1da1b025-cabc-6f04-bde5-e50830d1ecf0@amd.com/ > > > > [rppt@kernel.org: > > * s/restore/collapse/ > > * update formatting per peterz > > * use 'struct ptdesc' instead of 'struct page' for list of page tables to > > be freed > > * try to collapse PMD first and if it succeeds move on to PUD as peterz > > suggested > > * flush TLB twice: for changes done in the original CPA call and after > > collapsing of large pages > > ] > > > > Link: https://lore.kernel.org/all/20200416213229.19174-1-kirill.shutemov@linux.intel.com > > Signed-off-by: Kirill A. Shutemov > > Co-developed-by: Mike Rapoport (Microsoft) > > Signed-off-by: Mike Rapoport (Microsoft) > > When I originally attempted this, the patch was dropped because of > performance regressions. Was it addressed somehow? > Also, the statement: "Change of attributes of the pages may lead to fragmentation of direct mapping over time and performance degradation as result. " Seems to contradict the findings reported at LSFMM by Mike before that direct map fragmentation does not incur performance penalty, so I don't see a point in contradicing those findings and confusing people further. Luis