From: Robert Richter <rric@kernel.org>
To: Vince Weaver <vince@deater.net>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Borislav Petkov <bp@alien8.de>, Jiri Olsa <jolsa@redhat.com>,
linux-kernel@vger.kernel.org, Namhyung Kim <namhyung@kernel.org>
Subject: Re: [PATCH v3 08/12] perf, persistent: Exposing persistent events using sysfs
Date: Fri, 23 Aug 2013 11:37:08 +0200 [thread overview]
Message-ID: <20130823093708.GA10223@rric.localhost> (raw)
In-Reply-To: <alpine.DEB.2.02.1308221344500.26486@pianoman.cluster.toy>
On 22.08.13 14:00:51, Vince Weaver wrote:
> On Thu, 22 Aug 2013, Robert Richter wrote:
> > + attr<index>:<bits> Set any field of the event
> > + attribute. The index is a
> > + decimal number that specifies
> > + the u64 value to be set within
> > + struct perf_event_attr.
>
> Ugh this is ugly.
It's not intended to be used by humans. ;) It is more for format
definitions that are provided by the kernel and that are parsed by
(perf) tools. Of course, a human could dig into it to figure out
that's going on.
> You might also want to specify that the "index"
> value starts at 0 which threw me for a bit when I was trying to figure
> out what was going on. You might also want to clarify the previous
> part of the document which uses "attr" to mean something else.
I thought it would be clear enough to refer to struct perf_event_attr.
Since the index usually starts with 0 as in the config fields, I
assumed this was clear in this case too. Though this can be documented
better.
> Is this endian clean? Will attr5:23 point to the same bit on a big-endian
> machine as on little-endian?
It is the endianness used in the syscall. Handled in the same way as
for the config fields. I don't see where this could be an issue.
> If we're going to have to have an ugly interface like this we might
> as well do something more human readable, since anything that parses this
> is going to have to rebuild the struct perf_event_attr by hand anyway
> (unless you propose people blindly set bits at offsets using pointer math
> which just sounds like a bad idea).
The format directories in /sys/bus/event_source/devices/*/format/ are
already there to make it human readable. A user never has to deal
directly with syntax provided there and may use already the
abstractions for the event syntax.
> For example, just give up and let someone specify the actual field name
> like "persistent" and have the tools handle that.
>
> /sys/bus/event_source/devices/persistent/events/mce_record
> persistent,config=106
>
> /sys/bus/event_source/devices/persistent/format/persistent
> attr_persistent
>
> That way you could also add things like
> /sys/bus/event_source/devices/persistent/format/precise_ip
> attr_precise_ip:0-1
The problem with this is that you have to implement this in the event
parser of perf tools. Thus, you need to update the parser for any
other syntax you want to use. This is not necessary with my
implementation. It already provides the above. The pmu driver just
need to add the sysfs entry.
.../format/precise_ip = attr5:15-16
Then, -e cycles,precise_ip=1 is the same as -e cycles:p. Looks very
human readable?
All this without updating perf tools.
Simply test this as follows:
# cp -rp /sys/devices/cpu/format/ /dev/shm/
# echo attr5:15-16 > /dev/shm/format/precise_ip
# mount --bind /dev/shm/format/ /sys/devices/cpu/format/
# find /sys/devices/cpu/format/
/sys/devices/cpu/format/
/sys/devices/cpu/format/precise_ip
/sys/devices/cpu/format/umask
/sys/devices/cpu/format/event
/sys/devices/cpu/format/cmask
/sys/devices/cpu/format/edge
/sys/devices/cpu/format/inv
# perf record -e cycles,precise_ip=1 sleep 1
Works out-of-the-box...
It's the whole intention of the new syntax that the event parser never
needs to be modified again for new attribute flags or any other
settings of the attributes. Now the syntax is also capable to describe
any event setup. Also consider that different architectures may
provide different syntax. In this case there is no need for
arch-specific code in the tools implementation, all is just brought by
sysfs.
> Although I still think exposing the full huge attr stuct via sysfs is just
> silly. Isn't there some better way? I'm not aware of any other syscall
> that exports things like this.
That's a different story. Guess there is no way back anymore now.
Though we are in a state all this is handable and covered by perf
tools.
-Robert
next prev parent reply other threads:[~2013-08-23 9:37 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-22 14:13 [PATCH v3 00/12] perf, persistent: Add persistent events Robert Richter
2013-08-22 14:13 ` [PATCH v3 01/12] perf, mmap: Factor out ring_buffer_detach_all() Robert Richter
2013-08-22 14:13 ` [PATCH v3 02/12] perf, mmap: Factor out try_get_event()/put_event() Robert Richter
2013-08-22 14:13 ` [PATCH v3 03/12] perf, mmap: Factor out perf_alloc/free_rb() Robert Richter
2013-08-22 14:13 ` [PATCH v3 04/12] perf, mmap: Factor out perf_get_fd() Robert Richter
2013-08-22 14:13 ` [PATCH v3 05/12] perf: Add persistent events Robert Richter
2013-08-22 14:13 ` [PATCH v3 06/12] mce, x86: Enable " Robert Richter
2013-08-22 14:13 ` [PATCH v3 07/12] perf, persistent: Implementing a persistent pmu Robert Richter
2013-08-22 14:13 ` [PATCH v3 08/12] perf, persistent: Exposing persistent events using sysfs Robert Richter
2013-08-22 18:00 ` Vince Weaver
2013-08-23 9:37 ` Robert Richter [this message]
2013-08-23 16:39 ` Vince Weaver
2013-08-27 11:16 ` Robert Richter
2013-08-22 14:13 ` [PATCH v3 09/12] perf, persistent: Use unique event ids Robert Richter
2013-08-22 14:13 ` [PATCH v3 10/12] perf, persistent: Implement reference counter for events Robert Richter
2013-08-22 14:13 ` [PATCH v3 11/12] perf, persistent: Dynamically resize list of sysfs entries Robert Richter
2013-08-22 14:13 ` [PATCH v3 12/12] [RFC] perf, persistent: ioctl functions to control persistency Robert Richter
2013-08-22 18:18 ` Vince Weaver
2013-08-23 9:11 ` Borislav Petkov
2013-08-23 9:45 ` Robert Richter
2013-08-23 10:44 ` Robert Richter
2013-08-23 11:34 ` Borislav Petkov
2013-08-23 17:07 ` Vince Weaver
2013-08-23 19:39 ` Borislav Petkov
2013-08-23 21:08 ` Vince Weaver
2013-08-23 21:09 ` Borislav Petkov
2013-08-27 11:54 ` Robert Richter
2013-08-27 12:22 ` Borislav Petkov
2013-08-27 12:41 ` Robert Richter
2013-08-27 12:48 ` Borislav Petkov
2013-08-23 10:07 ` Robert Richter
2013-08-27 12:17 ` Robert Richter
2013-08-24 9:38 ` [PATCH v3 00/12] perf, persistent: Add persistent events Borislav Petkov
2013-08-27 12:27 ` Robert Richter
2013-08-27 12:38 ` Borislav Petkov
2014-03-28 14:54 ` Jean Pihet
2014-03-29 9:42 ` Borislav Petkov
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=20130823093708.GA10223@rric.localhost \
--to=rric@kernel.org \
--cc=acme@infradead.org \
--cc=bp@alien8.de \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=vince@deater.net \
/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).