Messages in this thread | | | From | Ian Rogers <> | Date | Mon, 20 Sep 2021 22:05:59 -0700 | Subject | Re: [PATCH v2] perf test: Workload test of metric and metricgroups |
| |
On Mon, Sep 20, 2021 at 3:00 AM John Garry <john.garry@huawei.com> wrote: > > On 17/09/2021 20:16, Ian Rogers wrote: > > On Thu, Sep 16, 2021 at 12:37 AM John Garry<john.garry@huawei.com> wrote: > >> On 16/09/2021 07:05, Ian Rogers wrote: > >>> Test every metric and metricgroup with 'true' as a workload. > >>> > >>> Signed-off-by: Ian Rogers<irogers@google.com> > >> Reviewed-by: John Garry<john.garry@huawei.com> > >> > >> 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 > > 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 > - 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
| |