[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1906272238460.32342@nanos.tec.linutronix.de>
Date: Thu, 27 Jun 2019 22:39:13 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
cc: Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
Alan Cox <alan.cox@...el.com>, Tony Luck <tony.luck@...el.com>,
"H. Peter Anvin" <hpa@...or.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Andi Kleen <andi.kleen@...el.com>,
Hans de Goede <hdegoede@...hat.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jordan Borgner <mail@...dan-borgner.de>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Mohammad Etemadi <mohammad.etemadi@...el.com>,
Ricardo Neri <ricardo.neri@...el.com>,
linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH 0/2] Speed MTRR programming up when we can
On Thu, 27 Jun 2019, Ricardo Neri wrote:
> By measuring the execution time of mtrr_aps_init() (from which MTRRs
> in all CPUs are programmed in lock-step at boot), I find savings in the
> time required to program MTRRs as follows:
>
> Platform time-with-wbinvd(ms) time-no-wbinvd(ms)
> 104-core (208 LP) Skylake 1437 28
> 2-core (4 LP) Haswell 114 2
Impressive!
Powered by blists - more mailing lists