Thread (8 messages) 8 messages, 4 authors, 2021-09-21

Re: [PATCH v2] perf test: Workload test of metric and metricgroups

From: Ian Rogers <irogers@google.com>
Date: 2021-09-21 05:06:15
Also in: lkml

On Mon, Sep 20, 2021 at 3:00 AM John Garry [off-list ref] wrote:
On 17/09/2021 20:16, Ian Rogers wrote:
quoted
On Thu, Sep 16, 2021 at 12:37 AM John Garry[off-list ref]  wrote:
quoted
On 16/09/2021 07:05, Ian Rogers wrote:
quoted
Test every metric and metricgroup with 'true' as a workload.

Signed-off-by: Ian Rogers<irogers@google.com>
Reviewed-by: John Garry<redacted>

Note that I also had a local test for pmu events:
for e in `$PERF list --raw-dump pmu`; do
    echo "Testing $e"
    result=$($PERF stat -v -e "$e" perf bench internals synthesize)
    if [[ "$result" =~ "$e" ]]; then
      echo "Event not printed: $e"
      exit 1
    fi
done

Is there any value in upstreaming this? I could not see same already
there. Or else make your new script generic, so that it accepts an
argument whether to test events or metrics or metricgroups
It is not easy to make a generic script with the current shell test
infrastructure. I made a variant of this test:
https://lore.kernel.org/linux-perf-users/20210917184240.2181186-2-irogers@google.com/T/#u (local)
For skylake it ran for 1m15s and so it may be too slow. Perhaps we
need to add to the test infrastructure with some kind of speed flag.
Hi Ian,

I suggested this before I realized that it would be called from "perf test".

You think that 1m15s could be considered too slow, but I think that it
could be much slower to now run "perf test" on some other systems. Like
my arm64 system - see series
https://lore.kernel.org/linux-perf-users/1631795665-240946-1-git-send-email-john.garry@huawei.com/T/#t (local)
- where I mention that we have >700 HW PMU events (before applying that
series to take advantage of the event merging). And each of those events
would be tested individually - slow...

So firstly maybe a speed or test level flag could be added before we try
this. Sorry for any inconvenience caused.
Hi John,

I think a flag would be best. I'll look to add a notion of test sizes,
as that mirrors what works well at Google. We can then tag a test as
small, medium, large and default to just say running small and medium
tests.

Thanks,
Ian
Thanks,
John
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help