linux-kernel - Re: [PATCH 0/2] perf: add new uncore command

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: <CABPqkBQEbpss=SGiFw+Aj7+MvO9nWcrtkawj4-e=cw+mJiUk4g@mail.gmail.com>
Date:	Thu, 31 Jan 2013 15:32:14 +0100
From:	Stephane Eranian <eranian@...gle.com>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...e.hu" <mingo@...e.hu>,
	"ak@...ux.intel.com" <ak@...ux.intel.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Jiri Olsa <jolsa@...hat.com>,
	Namhyung Kim <namhyung.kim@....com>
Subject: Re: [PATCH 0/2] perf: add new uncore command

On Thu, Jan 31, 2013 at 3:21 PM, Ingo Molnar <mingo@...nel.org> wrote:
>
> * Stephane Eranian <eranian@...gle.com> wrote:
>
>> This patchset adds a new command to perf: perf uncore.
>> It is used to measure processor socket-level metrics
>> on a system-wide basis and at all priv levels.
>>
>> The command comes with a set of predefined key metrics
>> which are useful to measure multi-socket system imbalance
>> and various bandwidths.
>>
>> The following metrics are currently defined:
>>   - memory bandwidth (Nehalem, Westmere, SandyBridge-EP)
>>   - PCIe bandwidth (SandyBridge-EP)
>>   - QPI bandwidth (SandyBridge-EP)
>>   - C-state residency (SandyBridge-EP)
>>
>> Others can be added in the future.
>>
>> The command provides options to modify the unit of the metrics
>> (default: MB/s for bandwidth).
>>
>> Example on Nehalem:
>>
>>  # perf uncore
>>  #------------------------------
>>  #           Socket0           |
>>  #------------------------------
>>  #        RAM Bandwidth        |
>>  #            Wr             Rd|
>>  #          MB/s           MB/s|
>>  #------------------------------
>>          4954.99       14897.29
>>          4953.97       14894.56
>>          4947.52       14874.97
>>
>> To make plotting easier, the output can be augmented with a timestamp:
>>
>>  # perf uncore -T
>>  #----------------------------------------
>>  #         |           Socket0           |
>>  #         |------------------------------
>>  #   Time  |        RAM Bandwidth        |
>>  #    in   |            Wr             Rd|
>>  #   secs  |          MB/s           MB/s|
>>  #----------------------------------------
>>           1        4952.50       14890.49
>>           2        4955.55       14900.19
>>           3        4949.13       14879.60
>>           4        4954.66       14896.26
>
> Looks really useful - how about naming it in a bit more generic
> way, because I'm quite sure this command will become popular and
> 'perf uncore' is a bit un-intutive.
>
> A couple of possibilities:
>
>   perf system
>   perf hw
>   perf hw-stat
>
I am fine with that.  I prefer hw or systems for the command name.

> and also adding subcommands instead of options for the various
> views/metrics, such as:
>
>   perf hw ram
>   perf hw pci
>   perf hw qpi
>   perf hw cstate

Yes, could do that. Even though having all of them measure at once
is also useful (this is how it currently works by default).

>   etc.
>
> A plain 'perf hw' command would then list the available
> sub-commands and inform the user about the (current) set of
> hw subsystems that provide metrics.
>
Yes. this is what perf uncore -L already does.

For instance on SNB-EP:
$ perf uncore -L
mem_bw : SNB-EP MEM Bandwidth
qpi_bw : SNB-EP QPI Bandwidth
pcie_bw : SNB-EP PCIe Bandwidth
cstate : SNB-EP C-state residency
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/