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: Ingo Molnar <mingo@xxxxxxxxxx>
- Date: Mon, 12 Mar 2018 18:41:20 +0100
- Cc: Andy Lutomirski <luto@xxxxxxxxxx>, "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>, "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: <CA+55aFya-fZQVi45axVpv4PF_b8yhHfDxx3xCTX+gbN5Ec9VUQ@mail.gmail.com>
- References: <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> <CA+55aFya-fZQVi45axVpv4PF_b8yhHfDxx3xCTX+gbN5Ec9VUQ@mail.gmail.com>
- User-agent: NeoMutt/20170609 (1.8.3)
* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 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".
Ok, fair enough - and the testing argument makes sense as well.
Thanks,
Ingo
--
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]