[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180331053956.uts5yhxfy7ud4bpf@gmail.com>
Date: Sat, 31 Mar 2018 07:39:56 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-mm <linux-mm@...ck.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Andrew Lutomirski <luto@...nel.org>,
Kees Cook <keescook@...gle.com>,
Hugh Dickins <hughd@...gle.com>,
Jürgen Groß <jgross@...e.com>,
the arch/x86 maintainers <x86@...nel.org>, namit@...are.com
Subject: Re: [PATCH 00/11] Use global pages with PTI
* Dave Hansen <dave.hansen@...ux.intel.com> wrote:
> On 03/30/2018 01:32 PM, Thomas Gleixner wrote:
> > On Fri, 30 Mar 2018, Dave Hansen wrote:
> >
> >> On 03/30/2018 05:17 AM, Ingo Molnar wrote:
> >>> BTW., the expectation on !PCID Intel hardware would be for global pages to help
> >>> even more than the 0.6% and 1.7% you measured on PCID hardware: PCID already
> >>> _reduces_ the cost of TLB flushes - so if there's not even PCID then global pages
> >>> should help even more.
> >>>
> >>> In theory at least. Would still be nice to measure it.
> >>
> >> I did the lseek test on a modern, non-PCID system:
> >>
> >> No Global pages (baseline): 6077741 lseeks/sec
> >> 94 Global pages (this set): 8433111 lseeks/sec
> >> +2355370 lseeks/sec (+38.8%)
> >
> > That's all kernel text, right? What's the result for the case where global
> > is only set for all user/kernel shared pages?
>
> Yes, that's all kernel text (94 global entries). Here's the number with
> just the entry data/text set global (88 global entries on this system):
>
> No Global pages (baseline): 6077741 lseeks/sec
> 88 Global Pages (kentry ): 7528609 lseeks/sec (+23.9%)
> 94 Global pages (this set): 8433111 lseeks/sec (+38.8%)
Very impressive!
Please incorporate the performance numbers in patches #9 and #11.
There were a couple of valid review comments which need to be addressed as well,
but other than that it all looks good to me and I plan to apply the next
iteration.
In fact I think I'll try to put it into the backporting tree: as PGE was really
the pre PTI status quo and thus we should expect few quirks/bugs in this area,
plus we still want to share as much core PTI logic with the -stable kernels as
possible. The performance plus doesn't hurt either ... after so much lost
performance.
Thanks,
Ingo
Powered by blists - more mailing lists