Commit 53c613fe "x86/speculation: Enable cross-hyperthread spectre v2 STIBP mitigation"
turns on STIBP all the time.
This causes large performance regression in many workloads.
One case is perlbench in the SpecInt Rate 2006 test suite which shows a
21% reduction in throughput.
There're also other reports of drop in performance on Python and PHP benchmarks:
https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=2
STIBP on all the time should not be the default option.
Turn off STIBP all the time for now till STIBP can be applied on
a per task basis.
Signed-off-by: Tim Chen <tim.c.chen(a)linux.intel.com>
---
arch/x86/kernel/cpu/bugs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c
index c37e66e..21a8f39 100644
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -332,7 +332,7 @@ static bool stibp_needed(void)
if (!boot_cpu_has(X86_FEATURE_STIBP))
return false;
- return true;
+ return false;
}
static void update_stibp_msr(void *info)
--
2.9.4
The patch titled
Subject: mm: use swp_offset as key in shmem_replace_page()
has been added to the -mm tree. Its filename is
mm-use-swp_offset-as-key-in-shmem_replace_page.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-use-swp_offset-as-key-in-shmem_…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-use-swp_offset-as-key-in-shmem_…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Yu Zhao <yuzhao(a)google.com>
Subject: mm: use swp_offset as key in shmem_replace_page()
We changed the key of swap cache tree from swp_entry_t.val to swp_offset.
We need to do so in shmem_replace_page() as well.
Link: http://lkml.kernel.org/r/20181121215442.138545-1-yuzhao@google.com
Fixes: f6ab1f7f6b2d ("mm, swap: use offset of swap entry as key of swap cache")
Signed-off-by: Yu Zhao <yuzhao(a)google.com>
Reviewed-by: Matthew Wilcox <willy(a)infradead.org>
Acked-by: Hugh Dickins <hughd(a)google.com>
Cc: <stable(a)vger.kernel.org> [4.9+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
--- a/mm/shmem.c~mm-use-swp_offset-as-key-in-shmem_replace_page
+++ a/mm/shmem.c
@@ -1509,11 +1509,13 @@ static int shmem_replace_page(struct pag
{
struct page *oldpage, *newpage;
struct address_space *swap_mapping;
+ swp_entry_t entry;
pgoff_t swap_index;
int error;
oldpage = *pagep;
- swap_index = page_private(oldpage);
+ entry.val = page_private(oldpage);
+ swap_index = swp_offset(entry);
swap_mapping = page_mapping(oldpage);
/*
@@ -1532,7 +1534,7 @@ static int shmem_replace_page(struct pag
__SetPageLocked(newpage);
__SetPageSwapBacked(newpage);
SetPageUptodate(newpage);
- set_page_private(newpage, swap_index);
+ set_page_private(newpage, entry.val);
SetPageSwapCache(newpage);
/*
_
Patches currently in -mm which might be from yuzhao(a)google.com are
mm-use-swp_offset-as-key-in-shmem_replace_page.patch
mm-dont-expose-page-to-fast-gup-before-its-ready.patch
From: Ben Hutchings <ben(a)decadent.org.uk>
Depending on which functions are inlined in util/pmu.c, the snprintf()
calls in perf_pmu__parse_{scale,unit,per_pkg,snapshot}() might trigger a
warning:
util/pmu.c: In function 'pmu_aliases':
util/pmu.c:178:31: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size between 0 and 4095 [-Werror=format-truncation=]
snprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
^~
I found this when trying to build perf from Linux 3.16 with gcc 8.
However I can reproduce the problem in mainline if I force
__perf_pmu__new_alias() to be inlined.
Suppress this by using scnprintf() as has been done elsewhere in perf.
Signed-off-by: Ben Hutchings <ben(a)decadent.org.uk>
Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Cc: Jiri Olsa <jolsa(a)redhat.com>
Cc: Namhyung Kim <namhyung(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: stable(a)vger.kernel.org
Link: http://lkml.kernel.org/r/20181111184524.fux4taownc6ndbx6@decadent.org.uk
Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com>
---
tools/perf/util/pmu.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 7e49baad304d..7348eea0248f 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -145,7 +145,7 @@ static int perf_pmu__parse_scale(struct perf_pmu_alias *alias, char *dir, char *
int fd, ret = -1;
char path[PATH_MAX];
- snprintf(path, PATH_MAX, "%s/%s.scale", dir, name);
+ scnprintf(path, PATH_MAX, "%s/%s.scale", dir, name);
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -175,7 +175,7 @@ static int perf_pmu__parse_unit(struct perf_pmu_alias *alias, char *dir, char *n
ssize_t sret;
int fd;
- snprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
+ scnprintf(path, PATH_MAX, "%s/%s.unit", dir, name);
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -205,7 +205,7 @@ perf_pmu__parse_per_pkg(struct perf_pmu_alias *alias, char *dir, char *name)
char path[PATH_MAX];
int fd;
- snprintf(path, PATH_MAX, "%s/%s.per-pkg", dir, name);
+ scnprintf(path, PATH_MAX, "%s/%s.per-pkg", dir, name);
fd = open(path, O_RDONLY);
if (fd == -1)
@@ -223,7 +223,7 @@ static int perf_pmu__parse_snapshot(struct perf_pmu_alias *alias,
char path[PATH_MAX];
int fd;
- snprintf(path, PATH_MAX, "%s/%s.snapshot", dir, name);
+ scnprintf(path, PATH_MAX, "%s/%s.snapshot", dir, name);
fd = open(path, O_RDONLY);
if (fd == -1)
--
2.14.5
On Thu, 22 Nov 2018 at 11:42, 陳雅正 <yacheng600221(a)gmail.com> wrote:
>
> Hi Dave,
> Thanks for your feedback. No issue found actually if I remove "volatile" on my platform. In my experience, if the value is volatile, adding "volatile" will be safer and no harm, that is why I add it by default. If you think it is not necessary, it's ok for me to remove it.
>
Don't add it unless you've got proof you need it, we don't want it
confusing people later.
Dave.