[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] Accessing LTTng-ust cpu_id event field inside an XML state provider

Great to hear!


On 18-03-09 11:24 AM, aleix wrote:
> Thank you Matthew and GeneviÃve, it works like a charm! :D
>
> On Fri, Mar 09, 2018 at 10:16:48AM -0500, GeneviÃve Bastien wrote:
>> Hi Aleix,
>>
>>
>> Your message is totally appropriate and this is exactly what this list
>> is for.
>>
>>
>> Matthew said it all and I have not much to enhance the explanation, only
>> maybe to prevent further questions in case you need it, but the context
>> fields (vpid, vtid, etc) are accessed in XML with
>>
>>
>> <stateAttribute type="eventField" value="context._vpid" />
>>
>> Thanks you for highlighting the missing details of the documentation.
>>
>> Out of curiosity, how did you get started with the XML analyses? Did you
>> read the Trace Compass documentation, did you find an analysis lying
>> around to copy-paste from? If so where? We'd like to improve the user
>> experience of the custom XML analyses (getting started and doing more
>> complex stuff) and knowing how you learned will help us improve that
>> process.
> Sure! I'm happy to help :) I will explain you my experience and
> opinions! :
>
> I started with XML analysis while searching some way to visualize
> custom LTTng tracepoints on Trace-Compass. I'm using LTTng to analyse
> the performance of HPC applications and debugging a custom Linux
> Kernel extension we are working into. I first read about them on
> the integrated Trace-Compass documentation. At the beginning I skipped
> the section "Data Drive Analysis" because the name was confusing,
> maybe something like "Custom Trace-Compass Views" of "User-defined
> Trace-Compass Views" would be more effective on attracting the
> attention of newcomers. I returned to this section later, after reading
> everything else :)
>
> At the beginning it was hard to grasp the entire concept (I did not
> even new what an .xsd was), but the trace-compass people on IRC helped me
> a lot to get started. I think that your documentation on XML analysis is
> clearly explained for someone that already understands how XSD works,
> but not for somebody new to the subject (maybe a bit more of
> introduction would help).
>
> Once I got my first view working I came across the necessity of doing
> something different than what it is shown on the examples so I learned
> the different options that could be used in each xml section by
> reading the tmf/org.eclipse.tracecompass.tmf.analysis.xml.core/src/org/eclipse/tracecompass/tmf/analysis/xml/core/module/*.xsd
> files. The embedded descriptions of the different attributes helped me
> a lot to understand each option!
>
> I have already done some simple views (like a per-CPU dynamic
> frequency and idle C-states view (which maybe you could be interested
> in)) and other more specific view for my work.  I will definitely
> continue creating custom view to help me debug applications, I think
> that this feature combined with the LTTng custom tracepoints is
> awesome! (ftrace support would be awesome as well for when grumpy
> sysadmins do not allow me to install LTTng (which happens quite often
> :( ))
>
> Please, do not hesitate to ask if I can further elaborate anything
> else!
>> Thanks, GeneviÃve
>>
>> On 2018-03-09 09:06 AM, aleix wrote:
>>> Hello!
>>>
>>> This is my first message on the list, please excuse me if it is
>>> not appropiate.
>>>
>>> I'm writing a custom state provider in XML and I'm wondering how
>>> can I access the CPU id of a user space event within the state
>>> provider. I have tried with:
>>>
>>>   <stateAttribute type="eventField" value="cpu_id" />
>>>   
>>> But it is not found. The babeltrace output of the LTTng trace
>>> shows me:
>>>
>>> [17:33:44.238047390] (+0.000000366) xeon08 nanos:ust_task_label: {
>>> cpu_id = 24 }, { vpid = 24505, vtid = 24557, procname =
>>> "cholesky-weakit" }, { task_id = 1, task_label = "dgemm" }
>>>
>>> so the "cpu_id" field is present, although is not one of the
>>> user-defined tracepoint parameters such as "task_id" or
>>> "task_label".
>>>
>>> Any hint?
>>>
>>> http://bsc.es/disclaimer
>>> _______________________________________________ tracecompass-dev
>>> mailing list tracecompass-dev@xxxxxxxxxxx To change your delivery
>>> options, retrieve your password, or unsubscribe from this list,
>>> visit https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
>> _______________________________________________ tracecompass-dev
>> mailing list tracecompass-dev@xxxxxxxxxxx To change your delivery
>> options, retrieve your password, or unsubscribe from this list,
>> visit https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
> http://bsc.es/disclaimer
> _______________________________________________
> tracecompass-dev mailing list
> tracecompass-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev