| Message ID | 1520963994-28477-22-git-send-email-ldufour@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | Speculative page faults | expand |
On Tue, 13 Mar 2018, Laurent Dufour wrote: > Add support for the new speculative faults event. > > Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Acked-by: David Rientjes <rientjes@google.com> Aside: should there be a new spec_flt field for struct task_struct that complements maj_flt and min_flt and be exported through /proc/pid/stat?
On Mon, Mar 26, 2018 at 02:44:48PM -0700, David Rientjes wrote: > On Tue, 13 Mar 2018, Laurent Dufour wrote: > > > Add support for the new speculative faults event. > > > > Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> > > Acked-by: David Rientjes <rientjes@google.com> > > Aside: should there be a new spec_flt field for struct task_struct that > complements maj_flt and min_flt and be exported through /proc/pid/stat? No. task_struct is already too bloated. If you need per process tracking you can always get it through trace points. -Andi
On Mon, 26 Mar 2018, Andi Kleen wrote: > > Aside: should there be a new spec_flt field for struct task_struct that > > complements maj_flt and min_flt and be exported through /proc/pid/stat? > > No. task_struct is already too bloated. If you need per process tracking > you can always get it through trace points. > Hi Andi, We have count_vm_event(PGFAULT); count_memcg_event_mm(vma->vm_mm, PGFAULT); in handle_mm_fault() but not counterpart for spf. I think it would be helpful to be able to determine how much faulting can be done speculatively if there is no per-process tracking without tracing.
On 10/04/2018 08:47, David Rientjes wrote: > On Mon, 26 Mar 2018, Andi Kleen wrote: > >>> Aside: should there be a new spec_flt field for struct task_struct that >>> complements maj_flt and min_flt and be exported through /proc/pid/stat? >> >> No. task_struct is already too bloated. If you need per process tracking >> you can always get it through trace points. >> > > Hi Andi, > > We have > > count_vm_event(PGFAULT); > count_memcg_event_mm(vma->vm_mm, PGFAULT); > > in handle_mm_fault() but not counterpart for spf. I think it would be > helpful to be able to determine how much faulting can be done > speculatively if there is no per-process tracking without tracing. That sounds to be a good idea, I will create a separate patch a dedicated speculative_pgfault counter as PGFAULT is. Thanks, Laurent.
diff --git a/tools/include/uapi/linux/perf_event.h b/tools/include/uapi/linux/perf_event.h index 6f873503552d..a6ddab9edeec 100644 --- a/tools/include/uapi/linux/perf_event.h +++ b/tools/include/uapi/linux/perf_event.h @@ -112,6 +112,7 @@ enum perf_sw_ids { PERF_COUNT_SW_EMULATION_FAULTS = 8, PERF_COUNT_SW_DUMMY = 9, PERF_COUNT_SW_BPF_OUTPUT = 10, + PERF_COUNT_SW_SPF = 11, PERF_COUNT_SW_MAX, /* non-ABI */ }; diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index ef351688b797..45b954019118 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -428,6 +428,7 @@ const char *perf_evsel__sw_names[PERF_COUNT_SW_MAX] = { "alignment-faults", "emulation-faults", "dummy", + "speculative-faults", }; static const char *__perf_evsel__sw_name(u64 config) diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c index 34589c427e52..2a8189c6d5fc 100644 --- a/tools/perf/util/parse-events.c +++ b/tools/perf/util/parse-events.c @@ -140,6 +140,10 @@ struct event_symbol event_symbols_sw[PERF_COUNT_SW_MAX] = { .symbol = "bpf-output", .alias = "", }, + [PERF_COUNT_SW_SPF] = { + .symbol = "speculative-faults", + .alias = "spf", + }, }; #define __PERF_EVENT_FIELD(config, name) \ diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l index 655ecff636a8..5d6782426b30 100644 --- a/tools/perf/util/parse-events.l +++ b/tools/perf/util/parse-events.l @@ -308,6 +308,7 @@ emulation-faults { return sym(yyscanner, PERF_TYPE_SOFTWARE, PERF_COUNT_SW_EM dummy { return sym(yyscanner, PERF_TYPE_SOFTWARE, PERF_COUNT_SW_DUMMY); } duration_time { return sym(yyscanner, PERF_TYPE_SOFTWARE, PERF_COUNT_SW_DUMMY); } bpf-output { return sym(yyscanner, PERF_TYPE_SOFTWARE, PERF_COUNT_SW_BPF_OUTPUT); } +speculative-faults|spf { return sym(yyscanner, PERF_TYPE_SOFTWARE, PERF_COUNT_SW_SPF); } /* * We have to handle the kernel PMU event cycles-ct/cycles-t/mem-loads/mem-stores separately. diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c index 2918cac7a142..00dd227959e6 100644 --- a/tools/perf/util/python.c +++ b/tools/perf/util/python.c @@ -1174,6 +1174,7 @@ static struct { PERF_CONST(COUNT_SW_ALIGNMENT_FAULTS), PERF_CONST(COUNT_SW_EMULATION_FAULTS), PERF_CONST(COUNT_SW_DUMMY), + PERF_CONST(COUNT_SW_SPF), PERF_CONST(SAMPLE_IP), PERF_CONST(SAMPLE_TID),
Add support for the new speculative faults event. Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> --- tools/include/uapi/linux/perf_event.h | 1 + tools/perf/util/evsel.c | 1 + tools/perf/util/parse-events.c | 4 ++++ tools/perf/util/parse-events.l | 1 + tools/perf/util/python.c | 1 + 5 files changed, 8 insertions(+)