Re: Ability for classifying of measurements

[Daniel Gutson <daniel.gutson@tallertechnologies.com>]

(2nd resend due to Majordomo rejection, this time as plain text..sorry
for inconveniences)


On Wed, Apr 20, 2016 at 10:26 AM, Daniel Gutson
<daniel.gutson@tallertechnologies.com> wrote:
>
> El 20/4/2016 10:08, "Andi Kleen" <andi@firstfloor.org> escribió:
>
 Hi Andi.
>
>>
>> Leonardo Boquillon <leonardo.boquillon@tallertechnologies.com> writes:
>> >
>> > In no way we intend this patch to be committed; we just want to show the
>> > idea
>> > and start a discussion instead, focusing on the idea first rather than
>> > on the
>> > design & code.
>>
>> That's good because the patch as written is a big security hole (and in
>> fact will not work on any systems with SMAP enabled)
>>
>> The basic concept seems reasonable, although a single address may be
>> too inflexible.
>
 Agree, this was the first step. What we would like to see implemented from
 this feature is, 1) some dwarf-aided ability to specify watched variables in
 the perf record command (e.g. perf record --groupby="::var1,
class1::staticvar2" ),
and 2) provide an API to the applications so they can
 communicate with perf_events telling what's going on, such as the example we
 are showing here (which is *just* an example to fuel this discussion). This
 API would lead to intrusively mess the code of the app but not more than
 people already do with debugging printfs; this would be very important for
 performance-centric applications.

 So, is there some consensus to start defining the API?
>
>>
>> Often the main request I hear is for a simple way for an application
>> to turn on/off profiling, and perhaps add markers to distinguish
>> phases. It many cases that may be good enough.
>>
>> -Andi
>>
>> --
>> ak@linux.intel.com -- Speaking for myself only



-- 

Daniel F. Gutson
Engineering Manager

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:    dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson