Re: [PATCH] perf: add /proc/perf_events file for dump perf events info

From: Jovi Zhang
Date: Thu Jul 05 2012 - 22:26:00 EST


Hi peter,

Very thanks for your comments!

>> 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?

Currently I using eye to figure out what happening in system using
this /proc/perf_events,
but this file should be parsed programmatically when if need.

>
>> 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.
>
In this patch version 1, I outputed some field info which might not
need very heavily,
so I removed oncpu(overlaped with cpu field) and attr flag in next
version patch, now it
seems more clearly than before, only output key point field info of perf event.

How about below version 2 patch(attached again)?