Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Tue, Nov 21, 2017 at 09:07:14AM -0800, Andi Kleen wrote: > On Tue, Nov 21, 2017 at 10:28:06AM +0100, Jiri Olsa wrote: > > On Mon, Nov 20, 2017 at 08:03:06AM -0800, Andi Kleen wrote: > > > > > Yes it is. > > > > > > > > > > It's for the complete sampling period because it is computed > > > > > over the delta from the last sample to the previous sample. > > > > > > > > > > There isn't really a metric at a point, it is always over a interval. > > > > > > > > agreed, it's the count we meassured from the last sample.. but the > > > > 'averaged' word above implies to me we compute some average over the > > > > 'sampling' period, which we dont do > > > > > > Do you have a better word in mind? > > > > > > AFAIK average is the right word for this because it's the summary > > > for that time period. > > > > the way I understand it is that we take the values from the current > > sample and count the metric value.. so the phrase: > > > > .. the metric computed is averaged over the whole sampling period, > > not just for the sample point ... > > > > does not make sense to me.. because we take the value of that > > single 'sample point'.. I dont see any average sum in there > > The current samples contains the sum of event counts for a sampling period. > > EventA-1 EventA-2EventA-3 EventA-4 > EventB-1 EventB-2 EventC-3 > > gap with no eventsoverflow > |-| > period-start period-end > ^ ^ > | | > previous sample current sample > > > So EventA = 4 and EventB = 3 at the sample point > > I generate a metric, let's say EventA / EventB. It applies > to the whole period. > > But the metric is over a longer time which does not have the same > behavior. For example the gap above doesn't have any events, while > they are clustered at the beginning and end of the sample period. > > But we're summing everything together. The metric doesn't know > that the gap is different than the busy period. > > That's what I'm trying to express with averaging. I see, so averaging to express the sum of the uneven distribution of the counts.. ook thanks for bearing with me ;-) jirka
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Tue, Nov 21, 2017 at 09:07:14AM -0800, Andi Kleen wrote: > On Tue, Nov 21, 2017 at 10:28:06AM +0100, Jiri Olsa wrote: > > On Mon, Nov 20, 2017 at 08:03:06AM -0800, Andi Kleen wrote: > > > > > Yes it is. > > > > > > > > > > It's for the complete sampling period because it is computed > > > > > over the delta from the last sample to the previous sample. > > > > > > > > > > There isn't really a metric at a point, it is always over a interval. > > > > > > > > agreed, it's the count we meassured from the last sample.. but the > > > > 'averaged' word above implies to me we compute some average over the > > > > 'sampling' period, which we dont do > > > > > > Do you have a better word in mind? > > > > > > AFAIK average is the right word for this because it's the summary > > > for that time period. > > > > the way I understand it is that we take the values from the current > > sample and count the metric value.. so the phrase: > > > > .. the metric computed is averaged over the whole sampling period, > > not just for the sample point ... > > > > does not make sense to me.. because we take the value of that > > single 'sample point'.. I dont see any average sum in there > > The current samples contains the sum of event counts for a sampling period. > > EventA-1 EventA-2EventA-3 EventA-4 > EventB-1 EventB-2 EventC-3 > > gap with no eventsoverflow > |-| > period-start period-end > ^ ^ > | | > previous sample current sample > > > So EventA = 4 and EventB = 3 at the sample point > > I generate a metric, let's say EventA / EventB. It applies > to the whole period. > > But the metric is over a longer time which does not have the same > behavior. For example the gap above doesn't have any events, while > they are clustered at the beginning and end of the sample period. > > But we're summing everything together. The metric doesn't know > that the gap is different than the busy period. > > That's what I'm trying to express with averaging. I see, so averaging to express the sum of the uneven distribution of the counts.. ook thanks for bearing with me ;-) jirka
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Tue, Nov 21, 2017 at 10:28:06AM +0100, Jiri Olsa wrote: > On Mon, Nov 20, 2017 at 08:03:06AM -0800, Andi Kleen wrote: > > > > Yes it is. > > > > > > > > It's for the complete sampling period because it is computed > > > > over the delta from the last sample to the previous sample. > > > > > > > > There isn't really a metric at a point, it is always over a interval. > > > > > > agreed, it's the count we meassured from the last sample.. but the > > > 'averaged' word above implies to me we compute some average over the > > > 'sampling' period, which we dont do > > > > Do you have a better word in mind? > > > > AFAIK average is the right word for this because it's the summary > > for that time period. > > the way I understand it is that we take the values from the current > sample and count the metric value.. so the phrase: > > .. the metric computed is averaged over the whole sampling period, > not just for the sample point ... > > does not make sense to me.. because we take the value of that > single 'sample point'.. I dont see any average sum in there The current samples contains the sum of event counts for a sampling period. EventA-1 EventA-2EventA-3 EventA-4 EventB-1 EventB-2 EventC-3 gap with no eventsoverflow |-| period-start period-end ^ ^ | | previous sample current sample So EventA = 4 and EventB = 3 at the sample point I generate a metric, let's say EventA / EventB. It applies to the whole period. But the metric is over a longer time which does not have the same behavior. For example the gap above doesn't have any events, while they are clustered at the beginning and end of the sample period. But we're summing everything together. The metric doesn't know that the gap is different than the busy period. That's what I'm trying to express with averaging. If you still don't like the word I will remove the sentence. I don't have a better term to describe the above. -Andi
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Tue, Nov 21, 2017 at 10:28:06AM +0100, Jiri Olsa wrote: > On Mon, Nov 20, 2017 at 08:03:06AM -0800, Andi Kleen wrote: > > > > Yes it is. > > > > > > > > It's for the complete sampling period because it is computed > > > > over the delta from the last sample to the previous sample. > > > > > > > > There isn't really a metric at a point, it is always over a interval. > > > > > > agreed, it's the count we meassured from the last sample.. but the > > > 'averaged' word above implies to me we compute some average over the > > > 'sampling' period, which we dont do > > > > Do you have a better word in mind? > > > > AFAIK average is the right word for this because it's the summary > > for that time period. > > the way I understand it is that we take the values from the current > sample and count the metric value.. so the phrase: > > .. the metric computed is averaged over the whole sampling period, > not just for the sample point ... > > does not make sense to me.. because we take the value of that > single 'sample point'.. I dont see any average sum in there The current samples contains the sum of event counts for a sampling period. EventA-1 EventA-2EventA-3 EventA-4 EventB-1 EventB-2 EventC-3 gap with no eventsoverflow |-| period-start period-end ^ ^ | | previous sample current sample So EventA = 4 and EventB = 3 at the sample point I generate a metric, let's say EventA / EventB. It applies to the whole period. But the metric is over a longer time which does not have the same behavior. For example the gap above doesn't have any events, while they are clustered at the beginning and end of the sample period. But we're summing everything together. The metric doesn't know that the gap is different than the busy period. That's what I'm trying to express with averaging. If you still don't like the word I will remove the sentence. I don't have a better term to describe the above. -Andi
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Mon, Nov 20, 2017 at 08:03:06AM -0800, Andi Kleen wrote: > > > Yes it is. > > > > > > It's for the complete sampling period because it is computed > > > over the delta from the last sample to the previous sample. > > > > > > There isn't really a metric at a point, it is always over a interval. > > > > agreed, it's the count we meassured from the last sample.. but the > > 'averaged' word above implies to me we compute some average over the > > 'sampling' period, which we dont do > > Do you have a better word in mind? > > AFAIK average is the right word for this because it's the summary > for that time period. the way I understand it is that we take the values from the current sample and count the metric value.. so the phrase: .. the metric computed is averaged over the whole sampling period, not just for the sample point ... does not make sense to me.. because we take the value of that single 'sample point'.. I dont see any average sum in there but my english might be borken and you mean that in a different way jirka
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Mon, Nov 20, 2017 at 08:03:06AM -0800, Andi Kleen wrote: > > > Yes it is. > > > > > > It's for the complete sampling period because it is computed > > > over the delta from the last sample to the previous sample. > > > > > > There isn't really a metric at a point, it is always over a interval. > > > > agreed, it's the count we meassured from the last sample.. but the > > 'averaged' word above implies to me we compute some average over the > > 'sampling' period, which we dont do > > Do you have a better word in mind? > > AFAIK average is the right word for this because it's the summary > for that time period. the way I understand it is that we take the values from the current sample and count the metric value.. so the phrase: .. the metric computed is averaged over the whole sampling period, not just for the sample point ... does not make sense to me.. because we take the value of that single 'sample point'.. I dont see any average sum in there but my english might be borken and you mean that in a different way jirka
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
> > Yes it is. > > > > It's for the complete sampling period because it is computed > > over the delta from the last sample to the previous sample. > > > > There isn't really a metric at a point, it is always over a interval. > > agreed, it's the count we meassured from the last sample.. but the > 'averaged' word above implies to me we compute some average over the > 'sampling' period, which we dont do Do you have a better word in mind? AFAIK average is the right word for this because it's the summary for that time period. -Andi
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
> > Yes it is. > > > > It's for the complete sampling period because it is computed > > over the delta from the last sample to the previous sample. > > > > There isn't really a metric at a point, it is always over a interval. > > agreed, it's the count we meassured from the last sample.. but the > 'averaged' word above implies to me we compute some average over the > 'sampling' period, which we dont do Do you have a better word in mind? AFAIK average is the right word for this because it's the summary for that time period. -Andi
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Mon, Nov 20, 2017 at 07:35:05AM -0800, Andi Kleen wrote: > On Mon, Nov 20, 2017 at 10:04:19AM +0100, Jiri Olsa wrote: > > On Fri, Nov 17, 2017 at 01:43:00PM -0800, Andi Kleen wrote: > > > > SNIP > > > > > --- > > > tools/perf/Documentation/perf-script.txt | 10 +++- > > > tools/perf/builtin-script.c | 97 > > > +++- > > > tools/perf/util/metricgroup.c| 4 ++ > > > 3 files changed, 108 insertions(+), 3 deletions(-) > > > > > > diff --git a/tools/perf/Documentation/perf-script.txt > > > b/tools/perf/Documentation/perf-script.txt > > > index 2811fcf684cb..974ceb12c7f3 100644 > > > --- a/tools/perf/Documentation/perf-script.txt > > > +++ b/tools/perf/Documentation/perf-script.txt > > > @@ -117,7 +117,7 @@ OPTIONS > > > Comma separated list of fields to print. Options are: > > > comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, > > > symoff, > > > srcline, period, iregs, uregs, brstack, brstacksym, flags, > > > bpf-output, brstackinsn, > > > -brstackoff, callindent, insn, insnlen, synth, phys_addr. > > > + brstackoff, callindent, insn, insnlen, synth, phys_addr, metric. > > > Field list can be prepended with the type, trace, sw or hw, > > > to indicate to which event type the field list applies. > > > e.g., -F sw:comm,tid,time,ip,sym and -F trace:time,cpu,trace > > > @@ -217,6 +217,14 @@ OPTIONS > > > > > > The brstackoff field will print an offset into a specific dso/binary. > > > > > > + With the metric option perf script can compute metrics for > > > + sampling periods, similar to perf stat. This requires > > > + specifying a group with multiple metrics with the :S option > > > + for perf record. perf will sample on the first event, and > > > + compute metrics for all the events in the group. Please note > > > + that the metric computed is averaged over the whole sampling > > > + period, not just for the sample point. > > > > hum, is it? I see you call perf_stat__reset_shadow_stats for every > > group start.. which I'd think means you see metric for current > > leader sample point > > Yes it is. > > It's for the complete sampling period because it is computed > over the delta from the last sample to the previous sample. > > There isn't really a metric at a point, it is always over a interval. agreed, it's the count we meassured from the last sample.. but the 'averaged' word above implies to me we compute some average over the 'sampling' period, which we dont do jirka
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Mon, Nov 20, 2017 at 07:35:05AM -0800, Andi Kleen wrote: > On Mon, Nov 20, 2017 at 10:04:19AM +0100, Jiri Olsa wrote: > > On Fri, Nov 17, 2017 at 01:43:00PM -0800, Andi Kleen wrote: > > > > SNIP > > > > > --- > > > tools/perf/Documentation/perf-script.txt | 10 +++- > > > tools/perf/builtin-script.c | 97 > > > +++- > > > tools/perf/util/metricgroup.c| 4 ++ > > > 3 files changed, 108 insertions(+), 3 deletions(-) > > > > > > diff --git a/tools/perf/Documentation/perf-script.txt > > > b/tools/perf/Documentation/perf-script.txt > > > index 2811fcf684cb..974ceb12c7f3 100644 > > > --- a/tools/perf/Documentation/perf-script.txt > > > +++ b/tools/perf/Documentation/perf-script.txt > > > @@ -117,7 +117,7 @@ OPTIONS > > > Comma separated list of fields to print. Options are: > > > comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, > > > symoff, > > > srcline, period, iregs, uregs, brstack, brstacksym, flags, > > > bpf-output, brstackinsn, > > > -brstackoff, callindent, insn, insnlen, synth, phys_addr. > > > + brstackoff, callindent, insn, insnlen, synth, phys_addr, metric. > > > Field list can be prepended with the type, trace, sw or hw, > > > to indicate to which event type the field list applies. > > > e.g., -F sw:comm,tid,time,ip,sym and -F trace:time,cpu,trace > > > @@ -217,6 +217,14 @@ OPTIONS > > > > > > The brstackoff field will print an offset into a specific dso/binary. > > > > > > + With the metric option perf script can compute metrics for > > > + sampling periods, similar to perf stat. This requires > > > + specifying a group with multiple metrics with the :S option > > > + for perf record. perf will sample on the first event, and > > > + compute metrics for all the events in the group. Please note > > > + that the metric computed is averaged over the whole sampling > > > + period, not just for the sample point. > > > > hum, is it? I see you call perf_stat__reset_shadow_stats for every > > group start.. which I'd think means you see metric for current > > leader sample point > > Yes it is. > > It's for the complete sampling period because it is computed > over the delta from the last sample to the previous sample. > > There isn't really a metric at a point, it is always over a interval. agreed, it's the count we meassured from the last sample.. but the 'averaged' word above implies to me we compute some average over the 'sampling' period, which we dont do jirka
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Mon, Nov 20, 2017 at 10:04:19AM +0100, Jiri Olsa wrote: > On Fri, Nov 17, 2017 at 01:43:00PM -0800, Andi Kleen wrote: > > SNIP > > > --- > > tools/perf/Documentation/perf-script.txt | 10 +++- > > tools/perf/builtin-script.c | 97 > > +++- > > tools/perf/util/metricgroup.c| 4 ++ > > 3 files changed, 108 insertions(+), 3 deletions(-) > > > > diff --git a/tools/perf/Documentation/perf-script.txt > > b/tools/perf/Documentation/perf-script.txt > > index 2811fcf684cb..974ceb12c7f3 100644 > > --- a/tools/perf/Documentation/perf-script.txt > > +++ b/tools/perf/Documentation/perf-script.txt > > @@ -117,7 +117,7 @@ OPTIONS > > Comma separated list of fields to print. Options are: > > comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, > > symoff, > > srcline, period, iregs, uregs, brstack, brstacksym, flags, > > bpf-output, brstackinsn, > > -brstackoff, callindent, insn, insnlen, synth, phys_addr. > > + brstackoff, callindent, insn, insnlen, synth, phys_addr, metric. > > Field list can be prepended with the type, trace, sw or hw, > > to indicate to which event type the field list applies. > > e.g., -F sw:comm,tid,time,ip,sym and -F trace:time,cpu,trace > > @@ -217,6 +217,14 @@ OPTIONS > > > > The brstackoff field will print an offset into a specific dso/binary. > > > > + With the metric option perf script can compute metrics for > > + sampling periods, similar to perf stat. This requires > > + specifying a group with multiple metrics with the :S option > > + for perf record. perf will sample on the first event, and > > + compute metrics for all the events in the group. Please note > > + that the metric computed is averaged over the whole sampling > > + period, not just for the sample point. > > hum, is it? I see you call perf_stat__reset_shadow_stats for every > group start.. which I'd think means you see metric for current > leader sample point Yes it is. It's for the complete sampling period because it is computed over the delta from the last sample to the previous sample. There isn't really a metric at a point, it is always over a interval. -Andi
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Mon, Nov 20, 2017 at 10:04:19AM +0100, Jiri Olsa wrote: > On Fri, Nov 17, 2017 at 01:43:00PM -0800, Andi Kleen wrote: > > SNIP > > > --- > > tools/perf/Documentation/perf-script.txt | 10 +++- > > tools/perf/builtin-script.c | 97 > > +++- > > tools/perf/util/metricgroup.c| 4 ++ > > 3 files changed, 108 insertions(+), 3 deletions(-) > > > > diff --git a/tools/perf/Documentation/perf-script.txt > > b/tools/perf/Documentation/perf-script.txt > > index 2811fcf684cb..974ceb12c7f3 100644 > > --- a/tools/perf/Documentation/perf-script.txt > > +++ b/tools/perf/Documentation/perf-script.txt > > @@ -117,7 +117,7 @@ OPTIONS > > Comma separated list of fields to print. Options are: > > comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, > > symoff, > > srcline, period, iregs, uregs, brstack, brstacksym, flags, > > bpf-output, brstackinsn, > > -brstackoff, callindent, insn, insnlen, synth, phys_addr. > > + brstackoff, callindent, insn, insnlen, synth, phys_addr, metric. > > Field list can be prepended with the type, trace, sw or hw, > > to indicate to which event type the field list applies. > > e.g., -F sw:comm,tid,time,ip,sym and -F trace:time,cpu,trace > > @@ -217,6 +217,14 @@ OPTIONS > > > > The brstackoff field will print an offset into a specific dso/binary. > > > > + With the metric option perf script can compute metrics for > > + sampling periods, similar to perf stat. This requires > > + specifying a group with multiple metrics with the :S option > > + for perf record. perf will sample on the first event, and > > + compute metrics for all the events in the group. Please note > > + that the metric computed is averaged over the whole sampling > > + period, not just for the sample point. > > hum, is it? I see you call perf_stat__reset_shadow_stats for every > group start.. which I'd think means you see metric for current > leader sample point Yes it is. It's for the complete sampling period because it is computed over the delta from the last sample to the previous sample. There isn't really a metric at a point, it is always over a interval. -Andi
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Fri, Nov 17, 2017 at 01:43:00PM -0800, Andi Kleen wrote: SNIP > --- > tools/perf/Documentation/perf-script.txt | 10 +++- > tools/perf/builtin-script.c | 97 > +++- > tools/perf/util/metricgroup.c| 4 ++ > 3 files changed, 108 insertions(+), 3 deletions(-) > > diff --git a/tools/perf/Documentation/perf-script.txt > b/tools/perf/Documentation/perf-script.txt > index 2811fcf684cb..974ceb12c7f3 100644 > --- a/tools/perf/Documentation/perf-script.txt > +++ b/tools/perf/Documentation/perf-script.txt > @@ -117,7 +117,7 @@ OPTIONS > Comma separated list of fields to print. Options are: > comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff, > srcline, period, iregs, uregs, brstack, brstacksym, flags, > bpf-output, brstackinsn, > -brstackoff, callindent, insn, insnlen, synth, phys_addr. > + brstackoff, callindent, insn, insnlen, synth, phys_addr, metric. > Field list can be prepended with the type, trace, sw or hw, > to indicate to which event type the field list applies. > e.g., -F sw:comm,tid,time,ip,sym and -F trace:time,cpu,trace > @@ -217,6 +217,14 @@ OPTIONS > > The brstackoff field will print an offset into a specific dso/binary. > > + With the metric option perf script can compute metrics for > + sampling periods, similar to perf stat. This requires > + specifying a group with multiple metrics with the :S option > + for perf record. perf will sample on the first event, and > + compute metrics for all the events in the group. Please note > + that the metric computed is averaged over the whole sampling > + period, not just for the sample point. hum, is it? I see you call perf_stat__reset_shadow_stats for every group start.. which I'd think means you see metric for current leader sample point jirka
Re: [PATCH v3 3/3] perf, tools, script: Allow computing metrics in perf script
On Fri, Nov 17, 2017 at 01:43:00PM -0800, Andi Kleen wrote: SNIP > --- > tools/perf/Documentation/perf-script.txt | 10 +++- > tools/perf/builtin-script.c | 97 > +++- > tools/perf/util/metricgroup.c| 4 ++ > 3 files changed, 108 insertions(+), 3 deletions(-) > > diff --git a/tools/perf/Documentation/perf-script.txt > b/tools/perf/Documentation/perf-script.txt > index 2811fcf684cb..974ceb12c7f3 100644 > --- a/tools/perf/Documentation/perf-script.txt > +++ b/tools/perf/Documentation/perf-script.txt > @@ -117,7 +117,7 @@ OPTIONS > Comma separated list of fields to print. Options are: > comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff, > srcline, period, iregs, uregs, brstack, brstacksym, flags, > bpf-output, brstackinsn, > -brstackoff, callindent, insn, insnlen, synth, phys_addr. > + brstackoff, callindent, insn, insnlen, synth, phys_addr, metric. > Field list can be prepended with the type, trace, sw or hw, > to indicate to which event type the field list applies. > e.g., -F sw:comm,tid,time,ip,sym and -F trace:time,cpu,trace > @@ -217,6 +217,14 @@ OPTIONS > > The brstackoff field will print an offset into a specific dso/binary. > > + With the metric option perf script can compute metrics for > + sampling periods, similar to perf stat. This requires > + specifying a group with multiple metrics with the :S option > + for perf record. perf will sample on the first event, and > + compute metrics for all the events in the group. Please note > + that the metric computed is averaged over the whole sampling > + period, not just for the sample point. hum, is it? I see you call perf_stat__reset_shadow_stats for every group start.. which I'd think means you see metric for current leader sample point jirka
