Re: Ability for classifying of measurements\

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

On Wed, Apr 20, 2016 at 2:47 PM, Andi Kleen <andi@firstfloor.org> wrote:
>>  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.
>
> perf probe has an ability to reference variables relative
> to a register or in a register, and parse dwarf for it.
>
> I'm not sure it's a good idea to have a lot of arbitrary memory
> accesses in the PMI handler (although there is already some for stack
> walking)
>
> One problem with global variables is that they can move
> around with ASLR, so it can be difficult to find them.
>
> If the variable is in a register you can already get it from the PEBS
> record on Intel CPUs.  There is no good tooling for it currently,
> but the information is in perf script output, and can be enabled
> for perf record.
>
> An easy way to implement it would be to use a
> global register variable (register asm("...") ...).
> However you would need to rebuild all your libraries to preserve
> the global register.
>
> Best would be to use an unused register. One that comes to
> mind on x86-64bit Linux is GS, which is normally only used by the kernel.

I kept thinking about all this, and I changed my mind towards a
simpler (a first step) yet useful approach.
In the same way people spread some printfs for old school debugging, I
keep the idea of some perf API made available
for the application (which calls depend on some flag, say -DNPERF
similar to -DNDEBUG, so if the macro is
not defined, calls have no effects).
The first relatively easy (again, but yet useful) feature that comes
to my mind, is the ability (from the app) to
label phases of the perf recording, including enabling, disabling, and
labelling.
For example, let's suppose that an application has an initialization
phase, then a communication with a server,
then data gathering, then processing, then storing the processed
results. Currently, all the recording and reporting would mix all that
measured information, whereas we could be interested in some phases
only (or disabling the rest).

Thus, the API could have:

perf_enable();
perf_disable();
perf_label(const char* label);

So, the application would appropriately call those functions; at
reporting, both a summary and a breakdown of analysis would be
performed.
A quick hack that comes to my mind is that perf_label just changes the
destination file of perf record, closing the previous file and opening
(potentially appending)
the specified in the argument. This way I think perf report could be
left unmodified, so the user would just do perf report
[labelled_file].

The communication from the application to perf_events (when enabled
with e.g. compiled wih NPERF) could be through some /proc/perf or any
other mechanism.

>
> With this pending patchkit[1] the application can write to it
> using WRGSBASE, previously it needed a syscall.

-ENOLINK

>
> Currently perf cannot log GS I believe, but that would be fairly
> easy to add. Would also need some tooling to make the value
> an extra sort key in perf report.
>
> -Andi
>

Thanks Andi.

   Daniel.


-- 

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