Re: [tip:x86/mm] x86/boot/compressed/64: Describe the logic behind the LA57 check
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip:x86/mm] x86/boot/compressed/64: Describe the logic behind the LA57 check
- From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 12 Mar 2018 10:12:38 -0700
- Cc: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Cyrill Gorcunov <gorcunov@xxxxxxxxxx>, Kees Cook <keescook@xxxxxxxxxxxx>, Matthew Wilcox <willy@xxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Borislav Petkov <bp@xxxxxxx>, Andy Shevchenko <andy.shevchenko@xxxxxxxxx>, Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>, Peter Anvin <hpa@xxxxxxxxx>, "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>, Jürgen Groß <jgross@xxxxxxxx>, linux-tip-commits@xxxxxxxxxxxxxxx, Dave Hansen <dave.hansen@xxxxxxxxx>
- In-reply-to: <CALCETrU8=_A9VzJMWuLouoyVQVLbnh_1etQK4tB4kvD8b51opQ@mail.gmail.com>
- References: <20180226180451.86788-2-kirill.shutemov@linux.intel.com> <tip-a403d798182f4f7be5e9bab56cfa37e9828fd92a@git.kernel.org> <20180312124027.GG4064@hirez.programming.kicks-ass.net> <20180312124337.vw7bchm6brfzghfa@node.shutemov.name> <20180312131055.GH4064@hirez.programming.kicks-ass.net> <20180312140449.oyngtgqppnjuh3lf@node.shutemov.name> <20180312143212.77z2ptyqbsbqdll3@gmail.com> <20180312145049.boh3wmaotim6sfh2@black.fi.intel.com> <CA+55aFyKOkO1BBYX+-SZyON2FA_FSc9YqVDLU9-pRj1=jh9sUw@mail.gmail.com> <CALCETrU8=_A9VzJMWuLouoyVQVLbnh_1etQK4tB4kvD8b51opQ@mail.gmail.com>
On Mon, Mar 12, 2018 at 10:06 AM, Andy Lutomirski <luto@xxxxxxxxxx> wrote:
>
> I'd be surprised if there's a noticeable performance hit on anything
> except the micro-est of benchmarks. We're talking one extra
> intermediate paging structure cache entry in use, maybe a few data
> cache lines, and (wild guess) 0 extra cycles on a TLB miss in the
> normal case. This is because the walks are almost never going to
> start at the root.
Probably. But VM people may disagree if they already have high TLB miss costs.
> The real hit will be the extra page table for every task.
.. and it's unclear how noticeable that might be. It's not like it's
per-thread, only per process, and very few people have so many
processes that a page per process matters.
But regardless, I think we're better off with a "wait and see" approach.
IOW, try to use 5-level whenever possible for now, and _if_ somebody
actually can show that 4-level page tables perform better or have some
other advantage, we can then try to be clever later when it's all
tested and it's just an optimization, not a "that code won't even run
normally and gets basically zero coverage".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]