From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
To: Robert Richter <robert.richter@amd.com>
Cc: peterz@infradead.org, Anton Blanchard <anton@au1.ibm.com>,
linux-kernel@vger.kernel.org, eranian@google.com,
acme@redhat.com, linuxppc-dev@ozlabs.org, paulus@samba.org,
mpjohn@us.ibm.com, mingo@kernel.org, asharma@fb.com
Subject: Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events
Date: Tue, 16 Oct 2012 11:31:48 -0700 [thread overview]
Message-ID: <20121016183148.GA25482@us.ibm.com> (raw)
In-Reply-To: <20121016100809.GS8285@erda.amd.com>
Robert Richter [robert.richter@amd.com] wrote:
| Sukadev,
|
| On 15.10.12 17:55:34, Robert Richter wrote:
| > On 11.10.12 18:28:39, Sukadev Bhattiprolu wrote:
| > > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_FIXED_POINT },
| > > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_LOAD_STORE },
| > > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_INSTRUCTION_FETCH },
| > > + { .type = PERF_TYPE_HARDWARE, .config = PERF_COUNT_HW_STALLED_CYCLES_BRANCH },
| >
| > Instead of adding new hardware event types I would prefer to use raw
| > events in conjunction with sysfs, see e.g. the intel-uncore
| > implementation. Something like:
| >
| > $ find /sys/bus/event_source/devices/cpu/events/
| > ...
| > /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
| > /sys/bus/event_source/devices/cpu/events/stalled-cycles-load-store
| > /sys/bus/event_source/devices/cpu/events/stalled-cycles-instruction-fetch
| > /sys/bus/event_source/devices/cpu/events/stalled-cycles-branch
| > ...
| > $ cat /sys/bus/event_source/devices/cpu/events/stalled-cycles-fixed-point
| > event=0xff,umask=0x00
| >
| > Perf tool works then out-of-the-box with:
| >
| > $ perf record -e cpu/stalled-cycles-fixed-point/ ...
|
| I refer here to arch/x86/kernel/cpu/perf_event_intel_uncore.c (should
| be in v3.7-rc1 or tip:perf/core). See the INTEL_UNCORE_EVENT_DESC()
| macro and 'if (type->event_descs) ...' in uncore_type_init(). The code
| should be reworked to be non-architectural.
Ok. I will look through that code. Does that mean we are trying to avoid
any more new hardware generic events ?
Also a broader question - is the sysfs approach intended for all raw events
or just for the generic events supported in the kernel ?
If it is intended for all events a CPU supports, isn't there a chance of
bloating kernel code ? Power7 has 530 events and Intel Nehalem (in libpfm)
seems to have 370 events. Would that mean we would need to represent all these
events in the kernel so they are available in sysfs ?
On a side note, how does the kernel on x86 use the 'config' information in
say /sys/bus/event_source/devices/cpu/format/cccr ? On Power7, the raw
code encodes the information such as the PMC to use for the event. Is that
how the 'config' info in Intel is used ?
Does the 'config' info change from system to system or is it static for
a given event on a given CPU ?
I guess I am trying to understand if this mapping between event-name (event
code) and the config info is something the kernel needs/uses or is it something
the kernel simply passes through from userspace to CPU ?
AFAICT, on the Power we use the raw codes to determine which PMC to select
and which bits to set in some registers. That selection is static for a given
CPU type such as Power7. If it is static, is it worth adding all this static
mapping (for 530 events) into the kernel ?
If we don't add to the kernel, we don't seem to have a way to specify the
events symbolically.
Thanks for you detailed comments.
|
| PMU registration is implemented for a longer time already for all
| architectures and pmu types:
|
| /sys/bus/event_source/devices/*
Yes I see this.
|
| But
|
| /sys/bus/event_source/devices/*/events/
Thanks for clarifying. I was looking to see if this was implemented too :-)
Sukadev
|
| exists only for a small number of pmus. Perf tool support of this was
| implemented with:
|
| a6146d5 perf/tool: Add PMU event alias support
|
| -Robert
|
| --
| Advanced Micro Devices, Inc.
| Operating System Research Center
next prev parent reply other threads:[~2012-10-16 18:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-12 1:28 [RFC][PATCH] perf: Add a few generic stalled-cycles events Sukadev Bhattiprolu
2012-10-15 5:26 ` Anshuman Khandual
2012-10-15 15:55 ` Robert Richter
2012-10-15 17:23 ` Arun Sharma
2012-10-16 5:28 ` Anshuman Khandual
2012-10-16 10:08 ` Robert Richter
2012-10-16 12:21 ` Stephane Eranian
2012-10-19 17:05 ` Sukadev Bhattiprolu
2012-10-16 18:31 ` Sukadev Bhattiprolu [this message]
2012-10-24 12:27 ` Peter Zijlstra
2012-10-31 6:40 ` Sukadev Bhattiprolu
2012-10-31 7:22 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121016183148.GA25482@us.ibm.com \
--to=sukadev@linux.vnet.ibm.com \
--cc=acme@redhat.com \
--cc=anton@au1.ibm.com \
--cc=asharma@fb.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@kernel.org \
--cc=mpjohn@us.ibm.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=robert.richter@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).