linux-kernel - Re: [PATCH 3/8] x86/mm/pat: Restore large pages after fragmentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z4ZD9exBt-JQiuS6@kernel.org>
Date: Tue, 14 Jan 2025 13:01:09 +0200
From: Mike Rapoport <rppt@...nel.org>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: "Kirill A. Shutemov" <kirill@...temov.name>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	Anton Ivanov <anton.ivanov@...bridgegreys.com>,
	Borislav Petkov <bp@...en8.de>,
	Brendan Higgins <brendan.higgins@...ux.dev>,
	Daniel Gomez <da.gomez@...sung.com>,
	Daniel Thompson <danielt@...nel.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	David Gow <davidgow@...gle.com>,
	Douglas Anderson <dianders@...omium.org>,
	Ingo Molnar <mingo@...hat.com>,
	Jason Wessel <jason.wessel@...driver.com>,
	Jiri Kosina <jikos@...nel.org>,
	Joe Lawrence <joe.lawrence@...hat.com>,
	Johannes Berg <johannes@...solutions.net>,
	Josh Poimboeuf <jpoimboe@...nel.org>,
	Luis Chamberlain <mcgrof@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Miroslav Benes <mbenes@...e.cz>, "H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Petr Mladek <pmladek@...e.com>, Petr Pavlu <petr.pavlu@...e.com>,
	Rae Moar <rmoar@...gle.com>, Richard Weinberger <richard@....at>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Shuah Khan <shuah@...nel.org>, Song Liu <song@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	kgdb-bugreport@...ts.sourceforge.net, kunit-dev@...glegroups.com,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
	linux-mm@...ck.org, linux-modules@...r.kernel.org,
	linux-trace-kernel@...r.kernel.org, linux-um@...ts.infradead.org,
	live-patching@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH 3/8] x86/mm/pat: Restore large pages after fragmentation

On Mon, Jan 13, 2025 at 10:01:13AM +0200, Kirill A. Shutemov wrote:
> On Sun, Jan 12, 2025 at 10:54:46AM +0200, Mike Rapoport wrote:
> > Hi Kirill,
> > 
> > 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" <kirill.shutemov@...ux.intel.com>
> > > > 
> > > > 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@...nel.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 <kirill.shutemov@...ux.intel.com>
> > > > Co-developed-by: Mike Rapoport (Microsoft) <rppt@...nel.org>
> > > > Signed-off-by: Mike Rapoport (Microsoft) <rppt@...nel.org>
> > > 
> > > When I originally attempted this, the patch was dropped because of
> > > performance regressions. Was it addressed somehow?
> > 
> > I didn't realize the patch was dropped because of performance regressions,
> > so I didn't address it.
> > 
> > Do you remember where did the regressions show up?
> 
> https://github.com/zen-kernel/zen-kernel/issues/169
> 
> My understanding is if userspace somewhat frequently triggers set_memory_*
> codepath we will get a performance hit.

This version of the patch will cause smaller performance hit because it
does not scan an entire PUD every time collapse_large_pages() is called.

Still, when I tweaked cpa-test to take some time measurements I see about
60% increase in the time it takes to perform set_memory operations.

Since we only really care about restoring large pages for ROX mapping, I'm
going to update the patch so that we'll try to collapse large pages only
from set_memory_rox().
 
> -- 
>   Kiryl Shutsemau / Kirill A. Shutemov

-- 
Sincerely yours,
Mike.