All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Borislav Petkov <bp@amd64.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>
Subject: Re: [RFC PATCH -v2 0/4] Persistent events
Date: Tue, 21 Aug 2012 12:30:50 +0200	[thread overview]
Message-ID: <1345545050.23018.95.camel@twins> (raw)
In-Reply-To: <1345139123-15212-1-git-send-email-bp@amd64.org>

On Thu, 2012-08-16 at 19:45 +0200, Borislav Petkov wrote:
> 
> off and on I get some free time to work on that, here's the latest
> incarnation. It contains review feedback from the earlier round.
> 
> Patch 1/4 adds a trace_add_file() interface which adds an additional
> file to debugfs, in this case the "persistent" file which contains the
> normal perf file descriptor sys_perf_event_open gives to the perf tool.
> 
> IOW, one gets:
> 
> /mnt/dbg/tracing/events/mce/mce_record/
> |-- enable
> |-- filter
> |-- format
> |-- id
> `-- persistent1
> 
> 0 directories, 5 files
> 
>  [ 1 is the CPU number so sticking all per-CPU descriptors in this
>  directory could get a little cluttered and ugly so I'll have to think
>  about that a bit more. ]
> 
> 3/4 is the meat which adds <kernel/events/persistent.c> and 4/4 shows
> how one can init a persistent event on a CPU.
> 
> What remains is adding code which can enable events on boot from the
> kernel cmdline and more testing.
> 
> As always, comments and suggestions are appreciated.


Good progress there, there's still a few things though:

 - the point also raised by Steven, I'm pretty sure that the placing of
   the debugfs files unfortunate. I would much rather see something
   like /debug/perf/persistent/$foo, also dropping your
   perf_event_desc::dir_name.

 - I would make perf_add_persistent_on_cpu() static and create something
   like perf_add_persistent() which iterates all CPUs and creates:
   "%s-%04d", perf_event_desc::fname, cpu. This needs a little extra for
   cpu-hotplug, not sure what to do there.

 - related to the first point, by not tying them to actual events you
   can create a persistent 'event' that contains multiple events. Its
   quite possible to create multiple kernel events and use the
   equivalent of PERF_EVENT_IOC_SET_OUTPUT on them to the exposed FD.

 - It might be good to provide means of changing the persistent event's
   buffer size, or maybe even 'destroy' persistent buffers.



  parent reply	other threads:[~2012-08-21 10:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-16 17:45 [RFC PATCH -v2 0/4] Persistent events Borislav Petkov
2012-08-16 17:45 ` [RFC PATCH -v2 1/4] trace events: Interface to add files to debugfs Borislav Petkov
2012-08-16 22:06   ` Steven Rostedt
2012-08-17  7:26     ` Borislav Petkov
2012-08-16 17:45 ` [RFC PATCH -v2 2/4] perf: Add persistent events Borislav Petkov
2012-08-16 17:45 ` [RFC PATCH -v2 3/4] perf: Add persistent event facilities Borislav Petkov
2012-08-16 22:12   ` Steven Rostedt
2012-08-17  7:27     ` Borislav Petkov
2012-12-09 12:06     ` Borislav Petkov
2012-08-21 10:08   ` Peter Zijlstra
2012-08-21 10:21   ` Peter Zijlstra
2012-08-16 17:45 ` [RFC PATCH -v2 4/4] persistent test Borislav Petkov
2012-08-16 20:12 ` [RFC PATCH -v2 0/4] Persistent events Jonathan Corbet
2012-08-16 20:55   ` Borislav Petkov
2012-08-16 21:13     ` Steven Rostedt
2012-08-16 21:41       ` Borislav Petkov
2012-08-16 22:00         ` Steven Rostedt
2012-08-17  7:38           ` Borislav Petkov
2012-08-17 15:20             ` Steven Rostedt
2012-08-17 17:06               ` Peter Zijlstra
2012-08-21 10:30 ` Peter Zijlstra [this message]
2012-08-21 13:11   ` Borislav Petkov
2012-08-21 13:41     ` Steven Rostedt
2012-08-21 13:50       ` Borislav Petkov
2012-08-21 14:03         ` Steven Rostedt

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=1345545050.23018.95.camel@twins \
    --to=peterz@infradead.org \
    --cc=borislav.petkov@amd.com \
    --cc=bp@amd64.org \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    /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.