Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tracecompass-dev] XML analysis on both ust and kernel lttng traces

Hi Zeno,

Good to know that it works!

About the 'tid' eventField I was mentioning, the 'tid' is a special field,
a bit like 'cpu'. The analysis will resolve this field through what we
call an aspect, that the kernel trace exposes. But I think you need some
plugins from the incubator for it to work from a UST trace, so nevermind
for now. I'll document it soon ;-)

Cheers,
Geneviève

On Wed, September 13, 2017 7:53 am, Zeno Endemann wrote:
> Hi Genevieve,
>
>
> Great, a state provider for an experiment works fine here, thank you.
>
>
> Your second paragraph I haven't quite understood; indeed I noticed
> kernel events come with the tid information, but I was talking about ust
> events, which do not have a tid eventField (unless you add it yourself or
> add a context) and I was trying to "synthesize" that field via monitoring
> the sched_switch event, which tells me which thread runs on which cpu at
> any time. And this appears to be working fine when I do that in a
> experiment state provider.
>
> Anyway, thanks again for the hint
>
>
> Cheers,
>
>
>
> On Tue, 12 Sep 2017 14:09:02 -0400, Genevieve Bastien wrote:
>
>> Hi Zeno,
>>
>>
>> Thanks for your interest in the XML analysis.
>>
>>
>> To answer your question: It is not possible to access another state
>> provider while building a state provider. But you can build an XML
>> analysis for an experiment by setting the trace type to that of the
>> experiment: org.eclipse.linuxtools.tmf.core.experiment.generic
>>
>>
>> But in your specific case, if what you are looking for is the thread
>> ID,
>> then there is a special eventField, 'tid' that you may use to find that
>> information wherever it is possible to find it, ie in your kernel
>> trace. So here you should replace the query CPU:cpu state attribute by a
>>  stateAttribute of type eventField and value tid and you'll find it.
>> But
>> make sure that the kernel trace has been opened and its analyses
>> completed before running the analysis.
>>
>> Best regards,
>> GeneviÃve
>>
>>
>> On 12.09.2017 09:49 Zeno Endemann wrote:
>>
>>> Hello,
>>>
>>>
>>> I'd like to combine kernel and ust events in the analysis - is it
>>> possible?
>>>
>>> As an example, I'd like to recover the information which thread
>>> caused a ust event (yes I know about lttng add-context --userspace
>>> --type=vtid,
>>> but let's assume this is not available). I tried the following, which
>>> didn't work for me (inside the same tmfxml element):
>>>
>>> <stateProvider id="foo1" version="1">
>>> <head>
>>> <traceType id="org.eclipse.linuxtools.lttng2.kernel.tracetype" />
>>> <label value="CPU TID map" />
>>> </head>
>>> <eventHandler eventName="sched_switch">
>>> <stateChange>
>>> <stateAttribute type="constant" value="CPUs" />
>>> <stateAttribute type="eventField" value="cpu" />
>>> <stateValue type="eventField" value="next_tid"/>
>>> </stateChange>
>>> </eventHandler>
>>> </stateProvider>
>>>
>>>
>>> <stateProvider id="foo2" version="1">
>>> <head>
>>> <traceType id="org.eclipse.linuxtools.lttng2.ust.tracetype" />
>>> <label value="UST Analysis" />
>>> </head>
>>> <eventHandler eventName="ust_myprog:event1">
>>> <stateChange>
>>> <stateAttribute type="constant" value="Threads" />
>>> <stateAttribute type="query">
>>> <stateAttribute type="constant" value="CPUs" />
>>> <stateAttribute type="eventField" value="cpu" />
>>> </stateAttribute>
>>> <stateValue type="int" value="..." />
>>> </stateChange>
>>> </eventHandler>
>>> </stateProvider>
>>>
>>>
>>> So I guess a stateProvider cannot access the state of another
>>> provider? Can I maybe define a single stateProvider on an Experiment
>>> (where I have
>>> both ust and kernel events combined)? Any other alternative?
>>>
>>> Thanks for any info!
>>>
>>>
>
> --
> Zeno Endemann | zeno.endemann@xxxxxxxx | Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> _______________________________________________
> 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
>
>




Back to the top