lkml.org 
[lkml]   [2019]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[PATCH 0/2] Speed MTRR programming up when we can
Date
Programming MTRR registers in multi-processor systems is a rather lengthy
process. Furthermore, all processors must program these registers in lock
step and with interrupts disabled; the process also involves flushing
caches and TLBs twice. As a result, the process may take a considerable
amount of time.

In some platforms, this can lead to a large skew of the refined-jiffies
clock source. Early when booting, if no other clock is available (e.g.,
booting with hpet=disabled), the refined-jiffies clock source is used to
monitor the TSC clock source. If the skew of refined-jiffies is too large,
Linux wrongly assumes that the TSC is unstable:

clocksource: timekeeping watchdog on CPU1: Marking clocksource
'tsc-early' as unstable because the skew is too large:
clocksource: 'refined-jiffies' wd_now: fffedc10 wd_last:
fffedb90 mask: ffffffff
clocksource: 'tsc-early' cs_now: 5eccfddebc cs_last: 5e7e3303d4
mask: ffffffffffffffff
tsc: Marking TSC unstable due to clocksource watchdog

As per my measurements, around 98% of the time needed by the procedure to
program MTRRs in multi-processor systems is spent flushing caches with
wbinvd(). As per the Section 11.11.8 of the Intel 64 and IA 32
Architectures Software Developer's Manual, it is not necessary to flush
caches if the CPU supports cache self-snooping. Thus, skipping the cache
flushes can reduce by several tens of milliseconds the time needed to
complete the programming of the MTRR registers.

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

However, there exist CPU models with errata that affect their self-
snooping capability. Such errata may cause unpredictable behavior, machine
check errors, or hangs. For instance:

"Where two different logical processors have the same code page
mapped with two different memory types Specifically if one code
page is mapped by one logical processor as write back and by
another as uncacheable and certain instruction timing conditions
occur the system may experience unpredictable behaviour." [1].

Similar errata are reported in other processors as well [2], [3], [4],
[5], and [6].

Thus, in order to confidently leverage self-snooping for the MTRR
programming algorithm, we must first clear such feature in models with
known errata.


Thanks and BR,
Ricardo

LP = Logical Processor

[1]. Erratum BF52,
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-3600-specification-update.pdf
[2]. Erratum BK47,
https://www.mouser.com/pdfdocs/2ndgencorefamilymobilespecificationupdate.pdf
[3]. Erratum AAO54,
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-c5500-c3500-spec-update.pdf
[4]. Errata AZ39, AZ42,
https://www.intel.com/content/dam/support/us/en/documents/processors/mobile/celeron/sb/320121.pdf
[5]. Errata AQ51, AQ102, AQ104,
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-dual-core-desktop-e2000-specification-update.pdf
[6]. Errata AN107, AN109,
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/pentium-dual-core-specification-update.pdf

Ricardo Neri (2):
x86/cpu/intel: Clear cache self-snoop capability in CPUs with known
errata
x86, mtrr: generic: Skip cache flushes on CPUs with cache
self-snooping

arch/x86/kernel/cpu/intel.c | 30 ++++++++++++++++++++++++++++++
arch/x86/kernel/cpu/mtrr/generic.c | 8 ++++++--
2 files changed, 36 insertions(+), 2 deletions(-)

--
2.17.1

\
 
 \ /
  Last update: 2019-06-27 20:44    [W:0.053 / U:31.504 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site