Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1650812 > unrolled thread

[PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

Back to article view | Back to linux.kernel

Contents

  [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-05-25 22:40 +0200
    [PATCHv1, RFC 2/8] x86/mm: Make virtual memory layout movable for CONFIG_X86_5LEVEL "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> - 2017-05-25 22:40 +0200
    Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-26 01:30 +0200
      Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging Andy Lutomirski <luto@kernel.org> - 2017-05-26 02:50 +0200
        Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level  paging Kevin Easton <kevin@guarana.org> - 2017-05-26 06:30 +0200
          Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging Andy Lutomirski <luto@kernel.org> - 2017-05-26 09:30 +0200
      Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level  paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-05-26 15:10 +0200
        Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level  paging Andi Kleen <ak@linux.intel.com> - 2017-05-26 15:40 +0200
        Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-26 18:00 +0200
          Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level  paging "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-05-26 18:00 +0200
            Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging Linus Torvalds <torvalds@linux-foundation.org> - 2017-05-26 18:20 +0200
          Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level  paging Dave Hansen <dave.hansen@intel.com> - 2017-05-26 21:30 +0200
            Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging hpa@zytor.com - 2017-05-26 21:50 +0200
          Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging hpa@zytor.com - 2017-05-26 21:30 +0200
        Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging hpa@zytor.com - 2017-05-26 22:20 +0200

#1650812 — [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

Here' my first attempt to bring boot-time between 4- and 5-level paging.
It looks not too terrible to me. I've expected it to be worse.

The basic idea is to implement the same logic as pgtable-nop4d.h provides,
but at runtime.

Runtime folding is only implemented for CONFIG_X86_5LEVEL=y case. With the
option disabled, we do compile-time folding.

Initially, I tried to fold pgd instread. I've got to shell, but it
required a lot of hacks as kernel threats pgd in a special way.

Few things are broken (see patch 7/8) and many things are not yet tested.
So more work is required.

I also haven't evaluated performance impact. We can look into some form of
boot-time code patching later if required.

Please review. Any feedback is welcome.

Kirill A. Shutemov (8):
  x86/boot/compressed/64: Detect and handle 5-level paging at boot-time
  x86/mm: Make virtual memory layout movable for CONFIG_X86_5LEVEL
  x86/mm: Make PGDIR_SHIFT and PTRS_PER_P4D variable
  x86/mm: Handle boot-time paging mode switching at early boot
  x86/mm: Fold p4d page table layer at runtime
  x86/mm: Replace compile-time checks for 5-level with runtime-time
  x86/mm: Hacks for boot-time switching between 4- and 5-level paging
  x86/mm: Allow to boot without la57 if CONFIG_X86_5LEVEL=y

 arch/x86/Kconfig                         |  4 +-
 arch/x86/boot/compressed/head_64.S       | 37 ++++++++++++++++++
 arch/x86/entry/entry_64.S                |  5 +++
 arch/x86/include/asm/kaslr.h             |  4 --
 arch/x86/include/asm/page_64.h           |  4 ++
 arch/x86/include/asm/page_64_types.h     | 15 +++-----
 arch/x86/include/asm/paravirt.h          |  3 +-
 arch/x86/include/asm/pgalloc.h           |  5 ++-
 arch/x86/include/asm/pgtable.h           | 10 ++++-
 arch/x86/include/asm/pgtable_32.h        |  2 +
 arch/x86/include/asm/pgtable_64_types.h  | 46 ++++++++++++++--------
 arch/x86/include/asm/processor.h         |  2 +-
 arch/x86/include/asm/required-features.h |  8 +---
 arch/x86/kernel/head64.c                 | 66 ++++++++++++++++++++++++++++----
 arch/x86/kernel/head_64.S                | 22 +++++++----
 arch/x86/mm/dump_pagetables.c            | 11 ++----
 arch/x86/mm/ident_map.c                  |  2 +-
 arch/x86/mm/init_64.c                    | 30 +++++++++------
 arch/x86/mm/kaslr.c                      | 16 ++------
 arch/x86/platform/efi/efi_64.c           |  4 +-
 arch/x86/power/hibernate_64.c            |  4 +-
 arch/x86/xen/Kconfig                     |  2 +-
 arch/x86/xen/mmu_pv.c                    |  2 +-
 23 files changed, 208 insertions(+), 96 deletions(-)

-- 
2.11.0

[toc] | [next] | [standalone]

#1650814 — [PATCHv1, RFC 2/8] x86/mm: Make virtual memory layout movable for CONFIG_X86_5LEVEL

We need to be able to adjust virtual memory layout at runtime to be able
to switch between 4- and 5-level paging at boot-time.

KASLR already has movable __VMALLOC_BASE, __VMEMMAP_BASE and __PAGE_OFFSET.
Let's re-use it.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/include/asm/kaslr.h            | 4 ----
 arch/x86/include/asm/page_64.h          | 4 ++++
 arch/x86/include/asm/page_64_types.h    | 2 +-
 arch/x86/include/asm/pgtable_64_types.h | 2 +-
 arch/x86/kernel/head64.c                | 9 +++++++++
 arch/x86/mm/kaslr.c                     | 8 --------
 6 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/kaslr.h b/arch/x86/include/asm/kaslr.h
index 1052a797d71d..683c9d736314 100644
--- a/arch/x86/include/asm/kaslr.h
+++ b/arch/x86/include/asm/kaslr.h
@@ -4,10 +4,6 @@
 unsigned long kaslr_get_random_long(const char *purpose);
 
 #ifdef CONFIG_RANDOMIZE_MEMORY
-extern unsigned long page_offset_base;
-extern unsigned long vmalloc_base;
-extern unsigned long vmemmap_base;
-
 void kernel_randomize_memory(void);
 #else
 static inline void kernel_randomize_memory(void) { }
diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h
index b4a0d43248cf..a12fb4dcdd15 100644
--- a/arch/x86/include/asm/page_64.h
+++ b/arch/x86/include/asm/page_64.h
@@ -10,6 +10,10 @@
 extern unsigned long max_pfn;
 extern unsigned long phys_base;
 
+extern unsigned long page_offset_base;
+extern unsigned long vmalloc_base;
+extern unsigned long vmemmap_base;
+
 static inline unsigned long __phys_addr_nodebug(unsigned long x)
 {
 	unsigned long y = x - __START_KERNEL_map;
diff --git a/arch/x86/include/asm/page_64_types.h b/arch/x86/include/asm/page_64_types.h
index 3f5f08b010d0..0126d6bc2eb1 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -42,7 +42,7 @@
 #define __PAGE_OFFSET_BASE      _AC(0xffff880000000000, UL)
 #endif
 
-#ifdef CONFIG_RANDOMIZE_MEMORY
+#if defined(CONFIG_RANDOMIZE_MEMORY) || defined(CONFIG_X86_5LEVEL)
 #define __PAGE_OFFSET           page_offset_base
 #else
 #define __PAGE_OFFSET           __PAGE_OFFSET_BASE
diff --git a/arch/x86/include/asm/pgtable_64_types.h b/arch/x86/include/asm/pgtable_64_types.h
index 06470da156ba..a9f77ead7088 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -85,7 +85,7 @@ typedef struct { pteval_t pte; } pte_t;
 #define __VMALLOC_BASE	_AC(0xffffc90000000000, UL)
 #define __VMEMMAP_BASE	_AC(0xffffea0000000000, UL)
 #endif
-#ifdef CONFIG_RANDOMIZE_MEMORY
+#if defined(CONFIG_RANDOMIZE_MEMORY) || defined(CONFIG_X86_5LEVEL)
 #define VMALLOC_START	vmalloc_base
 #define VMEMMAP_START	vmemmap_base
 #else
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 9403633f4c7c..408ed402db1a 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -38,6 +38,15 @@ extern pmd_t early_dynamic_pgts[EARLY_DYNAMIC_PAGE_TABLES][PTRS_PER_PMD];
 static unsigned int __initdata next_early_pgt;
 pmdval_t early_pmd_flags = __PAGE_KERNEL_LARGE & ~(_PAGE_GLOBAL | _PAGE_NX);
 
+#if defined(CONFIG_RANDOMIZE_MEMORY) || defined(CONFIG_X86_5LEVEL)
+unsigned long page_offset_base = __PAGE_OFFSET_BASE;
+EXPORT_SYMBOL(page_offset_base);
+unsigned long vmalloc_base = __VMALLOC_BASE;
+EXPORT_SYMBOL(vmalloc_base);
+unsigned long vmemmap_base = __VMEMMAP_BASE;
+EXPORT_SYMBOL(vmemmap_base);
+#endif
+
 static void __init *fixup_pointer(void *ptr, unsigned long physaddr)
 {
 	return ptr - (void *)_text + (void *)physaddr;
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index af599167fe3c..e6420b18f6e0 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -53,14 +53,6 @@ static const unsigned long vaddr_end = EFI_VA_END;
 static const unsigned long vaddr_end = __START_KERNEL_map;
 #endif
 
-/* Default values */
-unsigned long page_offset_base = __PAGE_OFFSET_BASE;
-EXPORT_SYMBOL(page_offset_base);
-unsigned long vmalloc_base = __VMALLOC_BASE;
-EXPORT_SYMBOL(vmalloc_base);
-unsigned long vmemmap_base = __VMEMMAP_BASE;
-EXPORT_SYMBOL(vmemmap_base);
-
 /*
  * Memory regions randomized by KASLR (except modules that use a separate logic
  * earlier during boot). The list is ordered based on virtual addresses. This
-- 
2.11.0

[toc] | [prev] | [next] | [standalone]

#1650962

On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
<kirill.shutemov@linux.intel.com> wrote:
> Here' my first attempt to bring boot-time between 4- and 5-level paging.
> It looks not too terrible to me. I've expected it to be worse.

If I read this right, you just made it a global on/off thing.

May I suggest possibly a different model entirely? Can you make it a
per-mm flag instead?

And then we

 (a) make all kthreads use the 4-level page tables

 (b) which means that all the init code uses the 4-level page tables

 (c) which means that all those checks for "start_secondary" etc can
just go away, because those all run with 4-level page tables.

Or is it just much too expensive to switch between 4-level and 5-level
paging at run-time?

              Linus

[toc] | [prev] | [next] | [standalone]

#1650999

On Thu, May 25, 2017 at 4:24 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com> wrote:
>> Here' my first attempt to bring boot-time between 4- and 5-level paging.
>> It looks not too terrible to me. I've expected it to be worse.
>
> If I read this right, you just made it a global on/off thing.
>
> May I suggest possibly a different model entirely? Can you make it a
> per-mm flag instead?
>
> And then we
>
>  (a) make all kthreads use the 4-level page tables
>
>  (b) which means that all the init code uses the 4-level page tables
>
>  (c) which means that all those checks for "start_secondary" etc can
> just go away, because those all run with 4-level page tables.
>
> Or is it just much too expensive to switch between 4-level and 5-level
> paging at run-time?
>

Even ignoring expensiveness, I'm not convinced it's practical.  AFAICT
you can't atomically switch the paging mode and CR3, so either you
need some magic page table with trampoline that works in both modes
(which is presumably doable with some trickery) or you need to flip
paging off.  Good luck if an NMI hits in the mean time.  There was
code like that once upon a time for EFI mixed mode, but it got deleted
due to triple-faults.

Doing this in switch_mm() sounds painful.

[toc] | [prev] | [next] | [standalone]

#1651074 — Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On Thu, May 25, 2017 at 05:40:16PM -0700, Andy Lutomirski wrote:
> On Thu, May 25, 2017 at 4:24 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> > <kirill.shutemov@linux.intel.com> wrote:
> >> Here' my first attempt to bring boot-time between 4- and 5-level paging.
> >> It looks not too terrible to me. I've expected it to be worse.
> >
> > If I read this right, you just made it a global on/off thing.
> >
> > May I suggest possibly a different model entirely? Can you make it a
> > per-mm flag instead?
> >
> > And then we
> >
> >  (a) make all kthreads use the 4-level page tables
> >
> >  (b) which means that all the init code uses the 4-level page tables
> >
> >  (c) which means that all those checks for "start_secondary" etc can
> > just go away, because those all run with 4-level page tables.
> >
> > Or is it just much too expensive to switch between 4-level and 5-level
> > paging at run-time?
> >
> 
> Even ignoring expensiveness, I'm not convinced it's practical.  AFAICT
> you can't atomically switch the paging mode and CR3, so either you
> need some magic page table with trampoline that works in both modes
> (which is presumably doable with some trickery) or you need to flip
> paging off.  Good luck if an NMI hits in the mean time.  There was
> code like that once upon a time for EFI mixed mode, but it got deleted
> due to triple-faults.

According to Intel's documentation you pretty much have to disable
paging anyway:

"The processor allows software to modify CR4.LA57 only outside of IA-32e
mode. In IA-32e mode, an attempt to modify CR4.LA57 using the MOV CR
instruction causes a general-protection exception (#GP)."

(If it weren't for that, maybe you could point the last entry in the PML4
at the PML4 itself, so it also works as a PML5 for accessing kernel
addresses? And of course make sure nothing gets loaded above 
0xffffff8000000000).

    - Kevin

[toc] | [prev] | [next] | [standalone]

#1651129

On Thu, May 25, 2017 at 9:18 PM, Kevin Easton <kevin@guarana.org> wrote:
> (If it weren't for that, maybe you could point the last entry in the PML4
> at the PML4 itself, so it also works as a PML5 for accessing kernel
> addresses? And of course make sure nothing gets loaded above
> 0xffffff8000000000).

This was an old trick done for a very different reason: it lets you
find your page tables at virtual addresses that depend only on the VA
whose page table you're looking for and the top-level slot that points
back to itself.  IIRC Windows used to do this for its own memory
management purposes.  A major downside is that an arbitrary write
vulnerability lets you write your own PTEs without any guesswork.

--Andy

[toc] | [prev] | [next] | [standalone]

#1651375 — Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On Thu, May 25, 2017 at 04:24:24PM -0700, Linus Torvalds wrote:
> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com> wrote:
> > Here' my first attempt to bring boot-time between 4- and 5-level paging.
> > It looks not too terrible to me. I've expected it to be worse.
> 
> If I read this right, you just made it a global on/off thing.
> 
> May I suggest possibly a different model entirely? Can you make it a
> per-mm flag instead?
> 
> And then we
> 
>  (a) make all kthreads use the 4-level page tables
> 
>  (b) which means that all the init code uses the 4-level page tables
> 
>  (c) which means that all those checks for "start_secondary" etc can
> just go away, because those all run with 4-level page tables.
> 
> Or is it just much too expensive to switch between 4-level and 5-level
> paging at run-time?

Hm..

I don't see how kernel threads can use 4-level paging. It doesn't work
from virtual memory layout POV. Kernel claims half of full virtual address
space for itself -- 256 PGD entries, not one as we would effectively have
in case of switching to 4-level paging. For instance, addresses, where
vmalloc and vmemmap are mapped, are not canonical with 4-level paging.

And you cannot see whole direct mapping of physical memory. Back to
highmem? (Please, no, please).

We could possible reduce number of PGD required by kernel. Currently,
layout for 5-level paging allows up-to 55-bit physical memory. It's
redundant as SDM claim that we never will get more than 52. So we could
reduce size of kernel part of layout by few bits, but not definitely to 1.

I don't see how it can possibly work.

Besides difficulties of getting switching between paging modes correct,
that Andy mentioned, it will also hurt performance. You cannot switch
between paging modes directly. It would require disabling paging
completely. It means we loose benefit from global page table entries on
such switching. More page-walks.

Even ignoring all of above, I don't see much benefit of having per-mm
switching. It adds complexity without much benefit -- saving few lines of
logic during early boot doesn't look as huge win to me.

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]

#1651394 — Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

> Even ignoring all of above, I don't see much benefit of having per-mm
> switching. It adds complexity without much benefit -- saving few lines of
> logic during early boot doesn't look as huge win to me.

Also giving kthreads a different VM would prevent lazy VM switching
when switching from/to idle, which can be quite important for performance
when doing fast IO.

-Andi

[toc] | [prev] | [next] | [standalone]

#1651448

On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
>
> I don't see how kernel threads can use 4-level paging. It doesn't work
> from virtual memory layout POV. Kernel claims half of full virtual address
> space for itself -- 256 PGD entries, not one as we would effectively have
> in case of switching to 4-level paging. For instance, addresses, where
> vmalloc and vmemmap are mapped, are not canonical with 4-level paging.

I would have just assumed we'd map the kernel in the shared part that
fits in the top 47 bits.

But it sounds like you can't switch back and forth anyway, so I guess it's moot.

Where *is* the LA57 documentation, btw? I had an old x86 architecture
manual, so I updated it, but LA57 isn't mentioned in the new one
either.

                       Linus

[toc] | [prev] | [next] | [standalone]

#1651450 — Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On Fri, May 26, 2017 at 08:51:48AM -0700, Linus Torvalds wrote:
> On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov
> <kirill@shutemov.name> wrote:
> >
> > I don't see how kernel threads can use 4-level paging. It doesn't work
> > from virtual memory layout POV. Kernel claims half of full virtual address
> > space for itself -- 256 PGD entries, not one as we would effectively have
> > in case of switching to 4-level paging. For instance, addresses, where
> > vmalloc and vmemmap are mapped, are not canonical with 4-level paging.
> 
> I would have just assumed we'd map the kernel in the shared part that
> fits in the top 47 bits.
> 
> But it sounds like you can't switch back and forth anyway, so I guess it's moot.
> 
> Where *is* the LA57 documentation, btw? I had an old x86 architecture
> manual, so I updated it, but LA57 isn't mentioned in the new one
> either.

It's in a separate white paper for now:

https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf

-- 
 Kirill A. Shutemov

[toc] | [prev] | [next] | [standalone]

#1651472

On Fri, May 26, 2017 at 8:58 AM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
>
> It's in a separate white paper for now:
>
> https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf

Thanks. It didn't show up with "LA57 site:intel.com" with google,
which is how I tried to find it ;)

                 Linus

[toc] | [prev] | [next] | [standalone]

#1651583 — Re: [PATCHv1, RFC 0/8] Boot-time switching between 4- and 5-level paging

On 05/26/2017 11:24 AM, hpa@zytor.com wrote:
> The only case where that even has any utility is for an application
> to want more than 128 TiB address space on a machine with no more
> than 64 TiB of RAM.  It is kind of a narrow use case, I think.

Doesn't more address space increase the effectiveness of ASLR?  I
thought KASLR, especially, was limited in its effectiveness because of a
lack of address space.

[toc] | [prev] | [next] | [standalone]

#1651594

On May 26, 2017 12:23:18 PM PDT, Dave Hansen <dave.hansen@intel.com> wrote:
>On 05/26/2017 11:24 AM, hpa@zytor.com wrote:
>> The only case where that even has any utility is for an application
>> to want more than 128 TiB address space on a machine with no more
>> than 64 TiB of RAM.  It is kind of a narrow use case, I think.
>
>Doesn't more address space increase the effectiveness of ASLR?  I
>thought KASLR, especially, was limited in its effectiveness because of
>a
>lack of address space.

The shortage of address space for KASLR is not addressable by LA57; rather, it would have to be addressed by compiling the kernel using a different (less efficient) memory model, presumably the "medium" memory model.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]

#1651585

On May 26, 2017 8:51:48 AM PDT, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov
><kirill@shutemov.name> wrote:
>>
>> I don't see how kernel threads can use 4-level paging. It doesn't
>work
>> from virtual memory layout POV. Kernel claims half of full virtual
>address
>> space for itself -- 256 PGD entries, not one as we would effectively
>have
>> in case of switching to 4-level paging. For instance, addresses,
>where
>> vmalloc and vmemmap are mapped, are not canonical with 4-level
>paging.
>
>I would have just assumed we'd map the kernel in the shared part that
>fits in the top 47 bits.
>
>But it sounds like you can't switch back and forth anyway, so I guess
>it's moot.
>
>Where *is* the LA57 documentation, btw? I had an old x86 architecture
>manual, so I updated it, but LA57 isn't mentioned in the new one
>either.
>
>                       Linus

As one of the major motivations for LA57 is that we expect that we will have machines with more than 2^46 bytes of memory in the near future, it isn't feasible in most cases to do per-VM LA57.

The only case where that even has any utility is for an application to want more than 128 TiB address space on a machine with no more than 64 TiB of RAM.  It is kind of a narrow use case, I think.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [next] | [standalone]

#1651603

On May 26, 2017 6:00:57 AM PDT, "Kirill A. Shutemov" <kirill@shutemov.name> wrote:
>On Thu, May 25, 2017 at 04:24:24PM -0700, Linus Torvalds wrote:
>> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
>> <kirill.shutemov@linux.intel.com> wrote:
>> > Here' my first attempt to bring boot-time between 4- and 5-level
>paging.
>> > It looks not too terrible to me. I've expected it to be worse.
>> 
>> If I read this right, you just made it a global on/off thing.
>> 
>> May I suggest possibly a different model entirely? Can you make it a
>> per-mm flag instead?
>> 
>> And then we
>> 
>>  (a) make all kthreads use the 4-level page tables
>> 
>>  (b) which means that all the init code uses the 4-level page tables
>> 
>>  (c) which means that all those checks for "start_secondary" etc can
>> just go away, because those all run with 4-level page tables.
>> 
>> Or is it just much too expensive to switch between 4-level and
>5-level
>> paging at run-time?
>
>Hm..
>
>I don't see how kernel threads can use 4-level paging. It doesn't work
>from virtual memory layout POV. Kernel claims half of full virtual
>address
>space for itself -- 256 PGD entries, not one as we would effectively
>have
>in case of switching to 4-level paging. For instance, addresses, where
>vmalloc and vmemmap are mapped, are not canonical with 4-level paging.
>
>And you cannot see whole direct mapping of physical memory. Back to
>highmem? (Please, no, please).
>
>We could possible reduce number of PGD required by kernel. Currently,
>layout for 5-level paging allows up-to 55-bit physical memory. It's
>redundant as SDM claim that we never will get more than 52. So we could
>reduce size of kernel part of layout by few bits, but not definitely to
>1.
>
>I don't see how it can possibly work.
>
>Besides difficulties of getting switching between paging modes correct,
>that Andy mentioned, it will also hurt performance. You cannot switch
>between paging modes directly. It would require disabling paging
>completely. It means we loose benefit from global page table entries on
>such switching. More page-walks.
>
>Even ignoring all of above, I don't see much benefit of having per-mm
>switching. It adds complexity without much benefit -- saving few lines
>of
>logic during early boot doesn't look as huge win to me.

It also makes no sense – the kernel threads only need one common page table anyway.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web