[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <878v78togq.fsf@sejong.aot.lge.com>
Date: Fri, 01 Feb 2013 17:42:13 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Stephane Eranian <eranian@...gle.com>
Cc: linux-kernel@...r.kernel.org, peterz@...radead.org, mingo@...e.hu,
ak@...ux.intel.com, acme@...hat.com, jolsa@...hat.com,
namhyung.kim@....com
Subject: Re: [PATCH 0/2] perf: add new uncore command
Hi, Stephane
On Thu, 31 Jan 2013 14:54:37 +0100, Stephane Eranian 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
>
> The code is split between generic layer (builtin-uncore.c) and
> an arch specific layer (arch/*/util/uncore.c). All events are
> hardcoded because they don't change for a given processor and
> metric computation requires combining multiple events.
>From a quick glancing, I think this is basically what perf stat does
with selected events, right? As we now have your interval printing I
can't find much difference.
And there's a patchset [1] from Jiri to support some kind of formula -
yeah, now I've written the correct spelling. :) - that might fit to this
purpose if you provide suitable formula file IMHO. So I guess we don't
need to have another command and can reuse perf stat, no?
Thanks,
Namhyung
[1] http://lwn.net/Articles/532634/
--
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/
Powered by blists - more mailing lists