x86/mm: Enable 5-level paging support by default
diff mbox series

Message ID 20190913095452.40592-1-kirill.shutemov@linux.intel.com
State New
Headers show
Series
  • x86/mm: Enable 5-level paging support by default
Related show

Commit Message

Kirill A. Shutemov Sept. 13, 2019, 9:54 a.m. UTC
Support of boot-time switching between 4- and 5-level paging mode is
upstream since 4.17.

We run internal testing with 5-level paging support enabled for a while
and it doesn't not cause any functional or performance regression on
4-level paging hardware.

The only 5-level paging related regressions I saw were in early boot
code that runs independently from CONFIG_X86_5LEVEL.

The next major release of distributions expected to have
CONFIG_X86_5LEVEL=y.

Enable the option by default. It may help to catch obscure bugs early.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

Comments

Dave Hansen Sept. 13, 2019, 6:20 p.m. UTC | #1
On 9/13/19 2:54 AM, Kirill A. Shutemov wrote:
> The next major release of distributions expected to have
> CONFIG_X86_5LEVEL=y.

It's probably worth noting that this exposes to two kinds of possible
performance issues:

First is the overhead of having the 5-level code on 4-level hardware.
We haven't seen any regressions there in quite a while.  Kirill talked
about this in the changelog.

Second is the overhead of having 5-level paging active on 5-level
hardware versus using 4-level paging on hardware *capable* of 5-level.
That is, of course, much harder to measure since 5-level hardware is not
publicly available.  But, we've tested this quite a bit and we're pretty
confident that it will not cause regressions, especially on systems
where apps don't opt in to the larger address space.

I do think endeavoring to have mainline's defaults match the most common
distro configs is a good idea, and now is as good of a time as any.

Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Ingo Molnar Sept. 16, 2019, 2:53 p.m. UTC | #2
* Dave Hansen <dave.hansen@intel.com> wrote:

> On 9/13/19 2:54 AM, Kirill A. Shutemov wrote:
> > The next major release of distributions expected to have
> > CONFIG_X86_5LEVEL=y.
> 
> It's probably worth noting that this exposes to two kinds of possible
> performance issues:
> 
> First is the overhead of having the 5-level code on 4-level hardware.
> We haven't seen any regressions there in quite a while.  Kirill talked
> about this in the changelog.
> 
> Second is the overhead of having 5-level paging active on 5-level
> hardware versus using 4-level paging on hardware *capable* of 5-level.
> That is, of course, much harder to measure since 5-level hardware is not
> publicly available.  But, we've tested this quite a bit and we're pretty
> confident that it will not cause regressions, especially on systems
> where apps don't opt in to the larger address space.
> 
> I do think endeavoring to have mainline's defaults match the most common
> distro configs is a good idea, and now is as good of a time as any.
> 
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>

Ok - in terms of timing it's obviously *way* too late for v5.4, so I've 
queued it up for the v5.5 merge window in tip:x86/mm. This should give it 
2-3 months of additional testing to shake out any weird interactions and 
quirks.

Thanks,

	Ingo

Patch
diff mbox series

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 222855cc0158..2f7cb91d850e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1483,6 +1483,7 @@  config X86_PAE
 
 config X86_5LEVEL
 	bool "Enable 5-level page tables support"
+	default y
 	select DYNAMIC_MEMORY_LAYOUT
 	select SPARSEMEM_VMEMMAP
 	depends on X86_64