From: Borislav Petkov <bp@alien8.de>
To: Shivank Garg <shivankg@amd.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Ard Biesheuvel <ardb+git@google.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Ard Biesheuvel <ardb@kernel.org>, Ingo Molnar <mingo@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Brian Gerst <brgerst@gmail.com>,
"Rao, Bharata Bhasker" <bharata@amd.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v3 1/7] x86/cpu: Use a new feature flag for 5 level paging
Date: Thu, 15 May 2025 21:11:31 +0200 [thread overview]
Message-ID: <20250515191131.GNaCY8Y7PI44akybDM@fat_crate.local> (raw)
In-Reply-To: <7c315a0d-1508-4310-b584-ecaeaba52296@amd.com>
On Thu, May 15, 2025 at 11:50:17PM +0530, Shivank Garg wrote:
> I've re-tested the performance concerns we discussed earlier regarding 5-level paging.
> Recent tests on a current kernel don't show any performance issues:
>
> AMD EPYC Zen 5 (SMT enabled).
> Linux HEAD 6.15.0-rc6+ 088d13246a46
>
> lmbench/lat_pagefault:
> numactl --membind=1 --cpunodebind=1 bin/x86_64-linux-gnu/lat_pagefault -N 100 1GB_randomfile
>
> Output values (50 runs, Mean, 2.5 percentile and 97.5 percentile, in microseconds):
>
> 4-level (no5lvl option)
> Mean: 0.138876
> 2.5% 97.5%
> 0.1384988 0.1392532
>
> 4-level (CONFIG_X86_5LEVEL=n)
> Mean: 0.137958
> 2.5% 97.5%
> 0.1376473 0.1382687
>
> 5-level
> Mean: 0.138904
> 2.5% 97.5%
> 0.1384789 0.1393291
>
> After repeating the experiments a few times, the observed difference(~1%) in mean values
> is under noise levels.
> I think these results address the performance concerns previously raised[1]. I don't
> foresee any issues in proceeding with the 5-level paging implementation
> simplification efforts[2].
>
> [1] https://lore.kernel.org/all/80734605-1926-4ac7-9c63-006fe3ea6b6a@amd.com
> [2] https://lore.kernel.org/all/20240621164406.256314-1-kirill.shutemov@linux.intel.com
I guess Kirill could dust off his patchset from [2] and that would get rid of
CONFIG_X86_5LEVEL and likely simplify that aspect considerably...
I'd say.
And then Ard's patches would get even simpler...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2025-05-15 19:11 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 10:42 [PATCH v3 0/7] x86: Robustify pgtable_l5_enabled() Ard Biesheuvel
2025-05-14 10:42 ` [PATCH v3 1/7] x86/cpu: Use a new feature flag for 5 level paging Ard Biesheuvel
2025-05-15 7:06 ` Ingo Molnar
2025-05-15 7:45 ` Ingo Molnar
2025-05-15 8:07 ` Kirill A. Shutemov
2025-05-15 8:22 ` Ingo Molnar
2025-05-15 10:12 ` Ard Biesheuvel
2025-05-15 23:24 ` Sean Christopherson
2025-05-16 8:31 ` Ard Biesheuvel
2025-05-15 9:51 ` Borislav Petkov
2025-05-15 10:17 ` Ard Biesheuvel
2025-05-15 10:39 ` Borislav Petkov
2025-05-15 10:57 ` Ard Biesheuvel
2025-05-15 13:11 ` Borislav Petkov
2025-05-15 13:33 ` Ard Biesheuvel
2025-05-17 16:59 ` David Laight
2025-05-15 18:20 ` Shivank Garg
2025-05-15 19:11 ` Borislav Petkov [this message]
2025-05-16 9:17 ` Kirill A. Shutemov
2025-05-14 10:42 ` [PATCH v3 2/7] x86/cpu: Allow caps to be set arbitrarily early Ard Biesheuvel
2025-05-15 6:56 ` Ingo Molnar
2025-05-15 7:50 ` Ingo Molnar
2025-05-15 7:55 ` Kirill A. Shutemov
2025-05-15 8:18 ` Ingo Molnar
2025-05-15 9:45 ` Ard Biesheuvel
2025-05-15 12:08 ` Ingo Molnar
2025-05-14 10:42 ` [PATCH v3 3/7] x86/asm-offsets: Export struct cpuinfo_x86 layout for asm use Ard Biesheuvel
2025-05-15 7:10 ` Ingo Molnar
2025-05-15 7:58 ` [tip: x86/core] x86/asm-offsets: Export certain 'struct cpuinfo_x86' fields for 64-bit asm use too tip-bot2 for Ard Biesheuvel
2025-05-14 10:42 ` [PATCH v3 4/7] x86/boot: Set 5-level paging CPU cap before entering C code Ard Biesheuvel
2025-05-15 8:00 ` Kirill A. Shutemov
2025-05-15 9:43 ` Ard Biesheuvel
2025-05-15 11:05 ` Kirill A. Shutemov
2025-05-14 10:42 ` [PATCH v3 5/7] x86/boot: Drop the early variant of pgtable_l5_enabled() Ard Biesheuvel
2025-05-14 10:42 ` [PATCH v3 6/7] x86/boot: Drop 5-level paging related variables and early updates Ard Biesheuvel
2025-05-14 10:42 ` [PATCH v3 7/7] x86/cpu: Make CPU capability overrides __ro_after_init Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250515191131.GNaCY8Y7PI44akybDM@fat_crate.local \
--to=bp@alien8.de \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=bharata@amd.com \
--cc=brgerst@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=shivankg@amd.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®