[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <sivhweds7p5sst2jpxanrj6qc7wlonqkod64nsr5cgttma7ntp@bhqespo3jdqz>
Date: Mon, 13 Jan 2025 10:01:13 +0200
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Mike Rapoport <rppt@...nel.org>
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 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.
--
Kiryl Shutsemau / Kirill A. Shutemov
Powered by blists - more mailing lists