Re: [tip:perf/core] perf/x86/intel: Force resched when TFA sysctl is modified
Vince On Tue, Apr 16, 2019 at 11:06 PM Ingo Molnar wrote: > > > * Vince Weaver wrote: > > > On Tue, 16 Apr 2019, tip-bot for Stephane Eranian wrote: > > > > > Commit-ID: f447e4eb3ad1e60d173ca997fcb2ef2a66f12574 > > > Gitweb: > > > https://git.kernel.org/tip/f447e4eb3ad1e60d173ca997fcb2ef2a66f12574 > > > Author: Stephane Eranian > > > AuthorDate: Mon, 8 Apr 2019 10:32:52 -0700 > > > Committer: Ingo Molnar > > > CommitDate: Tue, 16 Apr 2019 12:19:35 +0200 > > > > > > perf/x86/intel: Force resched when TFA sysctl is modified > > > > What's TFA? Tuna-fish-alarm? > > Heh, I wish! :-) > Sorry about the confusion. I was just trying to mimic the function names that Peter used in the code. Hard to fit the whole sysctl name in the title, anyway. > > [...] Nowhere in the commit or in the code does it ever say what a TFA > > is or why we'd want to resched when it is modified. > > Yeah, it's the TSX-Force-Abort acronym - Intel has numbed our general > dislike to random acrynyms ... > > Peter and me usually fix such changelog context omissions, but this one > slipped through. :-/ > > The commit is too deep down perf/core already to rebase it just for the > changelog, but if we are going to rebase it for some functional reason > I'll take care of it next time around. > > TFA. (Thanks For your Assistance. :-) > > Ingo
Re: [tip:perf/core] perf/x86/intel: Force resched when TFA sysctl is modified
* Vince Weaver wrote: > On Tue, 16 Apr 2019, tip-bot for Stephane Eranian wrote: > > > Commit-ID: f447e4eb3ad1e60d173ca997fcb2ef2a66f12574 > > Gitweb: > > https://git.kernel.org/tip/f447e4eb3ad1e60d173ca997fcb2ef2a66f12574 > > Author: Stephane Eranian > > AuthorDate: Mon, 8 Apr 2019 10:32:52 -0700 > > Committer: Ingo Molnar > > CommitDate: Tue, 16 Apr 2019 12:19:35 +0200 > > > > perf/x86/intel: Force resched when TFA sysctl is modified > > What's TFA? Tuna-fish-alarm? Heh, I wish! :-) > [...] Nowhere in the commit or in the code does it ever say what a TFA > is or why we'd want to resched when it is modified. Yeah, it's the TSX-Force-Abort acronym - Intel has numbed our general dislike to random acrynyms ... Peter and me usually fix such changelog context omissions, but this one slipped through. :-/ The commit is too deep down perf/core already to rebase it just for the changelog, but if we are going to rebase it for some functional reason I'll take care of it next time around. TFA. (Thanks For your Assistance. :-) Ingo
Re: [tip:perf/core] perf/x86/intel: Force resched when TFA sysctl is modified
On Tue, Apr 16, 2019 at 12:28:00PM -0400, Vince Weaver wrote:
> On Tue, 16 Apr 2019, tip-bot for Stephane Eranian wrote:
>
> > Commit-ID: f447e4eb3ad1e60d173ca997fcb2ef2a66f12574
> > Gitweb:
> > https://git.kernel.org/tip/f447e4eb3ad1e60d173ca997fcb2ef2a66f12574
> > Author: Stephane Eranian
> > AuthorDate: Mon, 8 Apr 2019 10:32:52 -0700
> > Committer: Ingo Molnar
> > CommitDate: Tue, 16 Apr 2019 12:19:35 +0200
> >
> > perf/x86/intel: Force resched when TFA sysctl is modified
>
> What's TFA? Tuna-fish-alarm? Nowhere in the commit or in the code does
> it ever say what a TFA is or why we'd want to resched when it is modified.
See commit: 400816f60c54 ("perf/x86/intel: Implement support for TSX Force
Abort")
Author: Peter Zijlstra (Intel)
Date: Tue Mar 5 22:23:18 2019 +0100
perf/x86/intel: Implement support for TSX Force Abort
Skylake (and later) will receive a microcode update to address a TSX
errata. This microcode will, on execution of a TSX instruction
(speculative or not) use (clobber) PMC3. This update will also provide
a new MSR to change this behaviour along with a CPUID bit to enumerate
the presence of this new MSR.
When the MSR gets set; the microcode will no longer use PMC3 but will
Force Abort every TSX transaction (upon executing COMMIT).
When TSX Force Abort (TFA) is allowed (default); the MSR gets set when
PMC3 gets scheduled and cleared when, after scheduling, PMC3 is
unused.
When TFA is not allowed; clear PMC3 from all constraints such that it
will not get used.
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Thomas Gleixner
Re: [tip:perf/core] perf/x86/intel: Force resched when TFA sysctl is modified
On Tue, 16 Apr 2019, tip-bot for Stephane Eranian wrote: > Commit-ID: f447e4eb3ad1e60d173ca997fcb2ef2a66f12574 > Gitweb: > https://git.kernel.org/tip/f447e4eb3ad1e60d173ca997fcb2ef2a66f12574 > Author: Stephane Eranian > AuthorDate: Mon, 8 Apr 2019 10:32:52 -0700 > Committer: Ingo Molnar > CommitDate: Tue, 16 Apr 2019 12:19:35 +0200 > > perf/x86/intel: Force resched when TFA sysctl is modified What's TFA? Tuna-fish-alarm? Nowhere in the commit or in the code does it ever say what a TFA is or why we'd want to resched when it is modified. Vince
[tip:perf/core] perf/x86/intel: Force resched when TFA sysctl is modified
Commit-ID: f447e4eb3ad1e60d173ca997fcb2ef2a66f12574
Gitweb: https://git.kernel.org/tip/f447e4eb3ad1e60d173ca997fcb2ef2a66f12574
Author: Stephane Eranian
AuthorDate: Mon, 8 Apr 2019 10:32:52 -0700
Committer: Ingo Molnar
CommitDate: Tue, 16 Apr 2019 12:19:35 +0200
perf/x86/intel: Force resched when TFA sysctl is modified
This patch provides guarantee to the sysadmin that when TFA is disabled, no PMU
event is using PMC3 when the echo command returns. Vice-Versa, when TFA
is enabled, PMU can use PMC3 immediately (to eliminate possible multiplexing).
$ perf stat -a -I 1000 --no-merge -e branches,branches,branches,branches
1.000123979125,768,725,208 branches
1.000562520125,631,000,456 branches
1.000942898125,487,114,291 branches
1.00116125,323,363,620 branches
2.004721306125,514,968,546 branches
2.005114560125,511,110,861 branches
2.005482722125,510,132,724 branches
2.005851245125,508,967,086 branches
3.006323475125,166,570,648 branches
3.006709247125,165,650,056 branches
3.007086605125,164,639,142 branches
3.007459298125,164,402,912 branches
4.007922698125,045,577,140 branches
4.008310775125,046,804,324 branches
4.008670814125,048,265,111 branches
4.009039251125,048,677,611 branches
5.009503373125,122,240,217 branches
5.009897067125,122,450,517 branches
Then on another connection, sysadmin does:
$ echo 1 >/sys/devices/cpu/allow_tsx_force_abort
Then perf stat adjusts the events immediately:
5.010286029125,121,393,483 branches
5.010646308125,120,556,786 branches
6.03588124,963,351,832 branches
6.011510331124,964,267,566 branches
6.011889913124,964,829,130 branches
6.012262996124,965,841,156 branches
7.012708299124,419,832,234 branches [79.69%]
7.012847908124,416,363,853 branches [79.73%]
7.013225462124,400,723,712 branches [79.73%]
7.013598191124,376,154,434 branches [79.70%]
8.014089834124,250,862,693 branches [74.98%]
8.014481363124,267,539,139 branches [74.94%]
8.014856006124,259,519,786 branches [74.98%]
8.014980848124,225,457,969 branches [75.04%]
9.015464576124,204,235,423 branches [75.03%]
9.015858587124,204,988,490 branches [75.04%]
9.016243680124,220,092,486 branches [74.99%]
9.016620104124,231,260,146 branches [74.94%]
And vice-versa if the syadmin does:
$ echo 0 >/sys/devices/cpu/allow_tsx_force_abort
Events are again spread over the 4 counters:
10.017096277124,276,230,565 branches [74.96%]
10.017237209124,228,062,171 branches [75.03%]
10.017478637124,178,780,626 branches [75.03%]
10.017853402124,198,316,177 branches [75.03%]
11.018334423124,602,418,933 branches [85.40%]
11.018722584124,602,921,320 branches [85.42%]
11.019095621124,603,956,093 branches [85.42%]
11.019467742124,595,273,783 branches [85.42%]
12.019945736125,110,114,864 branches
12.020330764125,109,334,472 branches
12.020688740125,109,818,865 branches
12.021054020125,108,594,014 branches
13.021516774125,109,164,018 branches
13.021903640125,108,794,510 branches
13.022270770125,107,756,978 branches
13.022630819125,109,380,471 branches
14.023114989125,133,140,817 branches
14.023501880125,133,785,858 branches
14.023868339125,133,852,700 branches
Signed-off-by: Stephane Eranian
Signed-off-by: Peter Zijlstra (Intel)
Cc: Alexander Shishkin
Cc: Arnaldo Carvalho de Melo
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Vince Weaver
Cc: kan.li...@intel.com
Cc: nelson.dso...@intel.com
Cc: to...@suse.com
Link: https://lkml.kernel.org/r/20190408173252.37932-3-eran...@google.com
Signed-off-by: Ingo Molnar
---
arch/x86/events/core.c | 4
arch/x86/events/intel/core.c | 50 ++--
arch/x86/events/perf_event.h | 1 +
3 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
index 87b50f4be201..fdd106267fd2 100644
--- a/arch/x86/events/core.c
+++ b/arch/x86/events/core.c
@@ -661,6 +661,10 @@ static inline int is_x86_event(struct perf_event *event)
return event->pmu ==
}
+struct pmu *x86_get_pmu(void)
+{
+ return
+}
/*
* Event scheduler state:
*
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 1bb59c4c59f2..8265b5026a19 100644
--- a/arch/x86/events/intel/core.c
+++
