| Message ID | 20190913095452.40592-1-kirill.shutemov@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/mm: Enable 5-level paging support by default | expand |
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>
* 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
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
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(+)