From: Peter Zijlstra <peterz@infradead.org>
To: Corey Ashford <cjashfor@linux.vnet.ibm.com>
Cc: Stephane Eranian <eranian@google.com>,
LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Lin Ming <ming.m.lin@intel.com>,
"robert.richter" <robert.richter@amd.com>,
fweisbec <fweisbec@gmail.com>, paulus <paulus@samba.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
Kay Sievers <kay.sievers@vrfy.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC][PATCH] perf: sysfs type id
Date: Wed, 17 Nov 2010 20:57:14 +0100 [thread overview]
Message-ID: <1290023834.2109.1240.camel@laptop> (raw)
In-Reply-To: <4CE43153.2070206@linux.vnet.ibm.com>
On Wed, 2010-11-17 at 11:47 -0800, Corey Ashford wrote:
>
> This is an interesting approach, though for the IBM WSP (aka PowerEN)
> chip, the config_format would have to be at a deeper level than the PMU,
> because the modifiers that affect the event, vary from event to event.
> Either that or you'd have to provide a complex union structure.
Eew.. how uhm creative ;-), yeah, not quite sure how to deal with that,
I wasn't planning to make a directory for each event, just a single file
with the u64 in it.
> However, above you say that you want to have "a few frequently
> used/common events". I thought that was the job of the perf "generic
> events". My understanding was that the sysfs tree was the solution for
> all events, including arch-specific, and seldom-used events.
My intent for the sysfs bits is to replace all the static stuff encoded
in PERF_TYPE_ and PERF_COUNT_ because it simply doesn't extend to a much
more dynamic world.
And GPUs/DSPs might have radically different common events than CPUs do.
Doing exhaustive lists in sysfs is simply going to waste tons of memory
for no real gain.
> Ingo
> pushed back on a user-space library solution (like libpfm4) because he
> wanted event info in sysfs (or some other mechanism by which the kernel
> could expose event info to user space).
I can't fully remember the details of that discussion.
> If there is going to be no place in sysfs for arch-specific events, I'll
> want to start pushing for perf to be able to use a user space library again.
>
> How about a compromise position: all of the arch-specific events are
> exposed to user space via sysfs iff some CONFIG_* variable to set to
> true. Something like CONFIG_EXPOSE_ALL_HW_PERF_EVENTS_IN_SYSFS.
> This way you would only use all that memory when it's explicitly
> configured in.
Ingo, any opinions?
next prev parent reply other threads:[~2010-11-17 19:57 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-09 21:45 [RFC][PATCH] perf: sysfs type id Peter Zijlstra
2010-11-09 22:11 ` Kay Sievers
2010-11-09 22:22 ` Peter Zijlstra
2010-11-09 22:40 ` Kay Sievers
2010-11-09 22:13 ` Greg KH
2010-11-09 23:36 ` Michael Ellerman
[not found] ` <AANLkTi=UftgQn0ydRd2wszqFtpRrkEcW7dzfapKKix_V@mail.gmail.com>
[not found] ` <1289350360.22787.9.camel@concordia>
[not found] ` <AANLkTikGHNkUN6t9rPhdE6XOQiqb5xAzH_9eY6L9h2H2@mail.gmail.com>
2010-11-10 1:10 ` Michael Ellerman
2010-11-10 1:19 ` Kay Sievers
2010-11-10 1:45 ` Michael Ellerman
2010-11-10 1:59 ` Kay Sievers
2010-11-10 3:37 ` Michael Ellerman
2010-11-10 2:11 ` Kay Sievers
2010-11-10 17:31 ` Greg KH
2010-11-10 12:27 ` Peter Zijlstra
2010-11-10 13:36 ` sysfs: Add an 'events' class. (was: Re: [RFC][PATCH] perf: sysfs type id) Ingo Molnar
2010-11-10 14:14 ` Kay Sievers
2010-11-10 15:00 ` Ingo Molnar
2010-11-11 6:39 ` Kay Sievers
2010-11-10 13:01 ` [RFC][PATCH] perf: sysfs type id Stephane Eranian
2010-11-10 14:10 ` Peter Zijlstra
2010-11-10 14:19 ` Peter Zijlstra
2010-11-10 20:08 ` Stephane Eranian
2010-11-10 20:32 ` Peter Zijlstra
2010-11-10 20:53 ` Stephane Eranian
2010-11-10 21:05 ` Peter Zijlstra
2010-11-17 2:35 ` Corey Ashford
2010-11-17 7:02 ` Kyle Moffett
2010-11-17 11:30 ` Peter Zijlstra
2010-11-17 11:25 ` Peter Zijlstra
2010-11-17 19:47 ` Corey Ashford
2010-11-17 19:57 ` Peter Zijlstra [this message]
2010-11-17 20:01 ` Peter Zijlstra
2010-11-17 21:39 ` Corey Ashford
2010-11-10 14:24 ` Stephane Eranian
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=1290023834.2109.1240.camel@laptop \
--to=peterz@infradead.org \
--cc=cjashfor@linux.vnet.ibm.com \
--cc=eranian@google.com \
--cc=fweisbec@gmail.com \
--cc=gregkh@suse.de \
--cc=hpa@zytor.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=paulus@samba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.