From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Jovi Zhang <bookjovi@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
LKML <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <fweisbec@redhat.com>
Subject: Re: [PATCH] perf: add /proc/perf_events file for dump perf events info
Date: Thu, 05 Jul 2012 15:54:00 +0200 [thread overview]
Message-ID: <1341496440.19870.69.camel@laptop> (raw)
In-Reply-To: <CACV3sb+rixP3HZ2=dJoe7x+9Rc5amRKu7dyj_4mcaZajwH2MSA@mail.gmail.com>
On Thu, 2012-07-05 at 21:38 +0800, Jovi Zhang wrote:
> On Thu, Jul 5, 2012 at 9:08 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > On Thu, 2012-07-05 at 21:02 +0800, Jovi Zhang wrote:
> >> > Watch all perf events in system wide can be very useful for perf subsystem issue handling,
> >> > to know which perf event is active in system,
> >> > perf event is a resouce, it would like to be managed easily for user, with more visable, like /proc/timer, etc...
> >> >
> >> > .jovi
> >>
> >>
> >> Ping...
> >
> > Never saw your reply, due to HTML it landed in the spam folder.
> >
> > That's a pretty non-specific answer.. again, why are you interested,
> > what specific problem are you wanting to solve.
> >
> > I've never had this need myself.
> >
> sorry, I will try to explain more.
>
> One problem I faced is about hw_breakpoint.
> As you known, hw_breakpoint use limit debug register in most architecture,
> In multi-user environment, sometime user cannot set hw_breakpoint because
> other user already occupy hw_breakpoint slots. currently, there don't
> have a way to know
> how many hw_breakpint perf event already is used in system, so that's
> why I thinking
> we might need a way to get perf event in systerm wide, with visable output.
Hrmm,. so this seems pretty specific to the horror of hw_breakpoint. And
yes those are unfortunate and weird.
But how would you use this proc file? Would you go read it
programmatically or just look at it as a user to figure out why stuff
doesn't work?
> Also this method is not only used for hw_breakpoint, others perf event
> might have similar problem,
> even other perf event don't have limit number, but it can make use of
> this /proc/perf_events
They have a limit alright, but we can round-robin them to hide this fact
(unless you tell it not to).
> Active perf events is cpu consumer at most time, at this point of
> view, system administrator also can use this
> /proc/perf_events to detect is there have any perf events is consuming cpu.
I doubt you can see which is consuming cycles, but you can see if
there's any in use.
> A method to detect perf event leak? of couse our perf subsystem is
> very stable right now, ingnore this :)
There's alway bugs ;-)
The problem I have with the patch is the global nature of it.. but if
something like this is require I guess I can live with it. But it might
be the current proposal is exposing too much information, I would
certainly not mark it readable for the entire world either.
next prev parent reply other threads:[~2012-07-05 13:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-05 8:23 [PATCH] perf: add /proc/perf_events file for dump perf events info Jovi Zhang
2012-07-05 8:27 ` Peter Zijlstra
[not found] ` <CACV3sb+aadXJYu7_JUedCodgQmF8d1q7OxSVoz=vwfc+Ow_caA@mail.gmail.com>
2012-07-05 13:02 ` Jovi Zhang
2012-07-05 13:08 ` Peter Zijlstra
2012-07-05 13:38 ` Jovi Zhang
2012-07-05 13:54 ` Peter Zijlstra [this message]
2012-07-06 2:26 ` Jovi Zhang
2012-09-13 21:03 ` David Ahern
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=1341496440.19870.69.camel@laptop \
--to=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=bookjovi@gmail.com \
--cc=fweisbec@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.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.