On May 26, 2017 6:00:57 AM PDT, "Kirill A. Shutemov" <kir...@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.shute...@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.
