linux-kernel - Re: [PATCH v1] perf stat: avoid 10ms limit for printing event counts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2600c74e-e9a2-c381-303d-d5e82012339f@linux.intel.com>
Date:   Tue, 27 Mar 2018 13:55:03 +0300
From:   Alexey Budankov <alexey.budankov@...ux.intel.com>
To:     Andi Kleen <ak@...ux.intel.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] perf stat: avoid 10ms limit for printing event counts

On 27.03.2018 12:06, Andi Kleen wrote:
>> When running perf stat -I for monitoring e.g. PCIe uncore counters and 
>> at the same time profiling some I/O workload by perf record e.g. for 
>> cpu-cycles and context switches, it is then possible to build and 
>> observe good-enough consolidated CPU/OS/IO(Uncore) performance picture 
>> for that workload.
> 
> At some point I still hope we can make uncore measurements in 
> perf record work. Kan tried at some point to allow multiple
> PMUs in a group, but was not successfull. But perhaps we
> can sample them from a software event instead.
> 
>>
>> The warning on possible runtime overhead is still preserved, however 
>> it is only visible when specifying -v option.
> 
> I would print it unconditionally. Very few people use -v.

If there is no objections I will resend the updated version.

Thanks,
Alexey

> 
> BTW better of course would be to occasionally measure the perf stat 
> cpu time and only print the warning if it's above some percentage
> of a CPU. But that would be much more work.
> 
> Rest looks ok.
> 
> 
> -Andi
>