[ltt-dev] ltt comm tracking

[ltt-dev] ltt comm tracking

[Matthieu CASTET]

Hi,

I use ltt on a 2.6.27 on an arm architecture.
It works quite well, but I have a minor problem :

my application sets thread name with prctl PR_SET_NAME. But ltt viewer
doesn't seem to saw it.

I don't know how/where ltt extracts the comm name, but may be a
tracepoint should be added in set_task_comm ?

Any idea how to make ltt use name set with prctl ?
This will make more easier to read trace for application with lot's of
threads.


Thanks

Matthieu CASTET

[ltt-dev] Tracing thread name (was: ltt comm tracking)

[Mathieu Desnoyers]

* Matthieu CASTET (matthieu.castet at parrot.com) wrote:
> Hi,
> 
> I use ltt on a 2.6.27 on an arm architecture.
> It works quite well, but I have a minor problem :
> 
> my application sets thread name with prctl PR_SET_NAME. But ltt viewer
> doesn't seem to saw it.
>

Hrm, I guess we might want to instrument set_task_comm as you propose to
get the correct process name, but if this gets us the thread name, I
think it's only an implementation side-effect:

If I look at the man page:

PRCTL(2)

       PR_SET_NAME (since Linux 2.6.9)
              Set the process name for the calling process, using the value in
              the location pointed to by (char *) arg2.  The name can be up to
              16  bytes  long,  and  should  be null terminated if it contains
              fewer bytes.

It seems to officially set the process name, not thread name.

The way LTTng handles thread names is by adding a userspace "thread
branding" event. It should be executed at thread startup. The downside
of the current LTTng approach is that we cannot know the name of threads
already executing before we started tracing.

Ideally, having something like prctl PR_SET/GET_THREAD_NAME would
probably make sense.

Mathieu

> I don't know how/where ltt extracts the comm name, but may be a
> tracepoint should be added in set_task_comm ?
> 
> Any idea how to make ltt use name set with prctl ?
> This will make more easier to read trace for application with lot's of
> threads.
> 
> 
> Thanks
> 
> Matthieu CASTET
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[ltt-dev] Tracing thread name (was: ltt comm tracking)

[Peter Zijlstra]

On Mon, 2009-08-03 at 09:48 -0400, Mathieu Desnoyers wrote:
> * Matthieu CASTET (matthieu.castet at parrot.com) wrote:
> > Hi,
> > 
> > I use ltt on a 2.6.27 on an arm architecture.
> > It works quite well, but I have a minor problem :
> > 
> > my application sets thread name with prctl PR_SET_NAME. But ltt viewer
> > doesn't seem to saw it.
> >
> 
> Hrm, I guess we might want to instrument set_task_comm as you propose to
> get the correct process name, but if this gets us the thread name, I
> think it's only an implementation side-effect:
> 
> If I look at the man page:
> 
> PRCTL(2)
> 
>        PR_SET_NAME (since Linux 2.6.9)
>               Set the process name for the calling process, using the value in
>               the location pointed to by (char *) arg2.  The name can be up to
>               16  bytes  long,  and  should  be null terminated if it contains
>               fewer bytes.
> 
> It seems to officially set the process name, not thread name.

Then the man page is wrong, it really only sets the task (thread) name.

> The way LTTng handles thread names is by adding a userspace "thread
> branding" event. It should be executed at thread startup. The downside
> of the current LTTng approach is that we cannot know the name of threads
> already executing before we started tracing.
> 
> Ideally, having something like prctl PR_SET/GET_THREAD_NAME would
> probably make sense.

Going by the current behaviour, you'd need to add process name.

fs/exec.c:

        void set_task_comm(struct task_struct *tsk, char *buf)
        {
                task_lock(tsk);
                strlcpy(tsk->comm, buf, sizeof(tsk->comm));
                task_unlock(tsk);
                perf_counter_comm(tsk);
        }

[ltt-dev] Tracing thread name

[Matthieu CASTET]

Hi Mathieu,

Mathieu Desnoyers a ?crit :
> * Matthieu CASTET (matthieu.castet at parrot.com) wrote:
>> Hi,
>>
>> I use ltt on a 2.6.27 on an arm architecture.
>> It works quite well, but I have a minor problem :
>>
>> my application sets thread name with prctl PR_SET_NAME. But ltt viewer
>> doesn't seem to saw it.
>>
> 
> Hrm, I guess we might want to instrument set_task_comm as you propose to
> get the correct process name, but if this gets us the thread name, I
> think it's only an implementation side-effect:

> The way LTTng handles thread names is by adding a userspace "thread
> branding" event. It should be executed at thread startup. The downside
> of the current LTTng approach is that we cannot know the name of threads
> already executing before we started tracing.
> 

Do you know if it is possible to patch my version to add such feature ?

I saw that the name already change in the trace before/after an exec.
How lltv get the new name ?
With "fs.exec" tracepoint ?
In that case I could fake a "fs.exec" tracepoint in set_task_comm.

Thanks

Matthieu

[ltt-dev] Tracing thread name

[Mathieu Desnoyers]

* Matthieu CASTET (matthieu.castet at parrot.com) wrote:
> Hi Mathieu,
> 
> Mathieu Desnoyers a ?crit :
> > * Matthieu CASTET (matthieu.castet at parrot.com) wrote:
> >> Hi,
> >>
> >> I use ltt on a 2.6.27 on an arm architecture.
> >> It works quite well, but I have a minor problem :
> >>
> >> my application sets thread name with prctl PR_SET_NAME. But ltt viewer
> >> doesn't seem to saw it.
> >>
> > 
> > Hrm, I guess we might want to instrument set_task_comm as you propose to
> > get the correct process name, but if this gets us the thread name, I
> > think it's only an implementation side-effect:
> 
> > The way LTTng handles thread names is by adding a userspace "thread
> > branding" event. It should be executed at thread startup. The downside
> > of the current LTTng approach is that we cannot know the name of threads
> > already executing before we started tracing.
> > 
> 
> Do you know if it is possible to patch my version to add such feature ?
> 
> I saw that the name already change in the trace before/after an exec.
> How lltv get the new name ?
> With "fs.exec" tracepoint ?
> In that case I could fake a "fs.exec" tracepoint in set_task_comm.

A better solution : you add a new event in both lttng and lttv, and
modify state.c to support your new event. The current event to brand
thread is named "userspace.thread_brand". Look for this in LTTV to see
all the sites that need to support the new event (there are very few).

Mathieu

> 
> Thanks
> 
> Matthieu
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[ltt-dev] Tracing thread name

[Matthieu CASTET]

Hi,

Mathieu Desnoyers a ?crit :
> * Matthieu CASTET (matthieu.castet at parrot.com) wrote:
>> Hi Mathieu,
>>
>> Mathieu Desnoyers a ?crit :
>> Do you know if it is possible to patch my version to add such feature ?
>>
>> I saw that the name already change in the trace before/after an exec.
>> How lltv get the new name ?
>> With "fs.exec" tracepoint ?
>> In that case I could fake a "fs.exec" tracepoint in set_task_comm.
> 
> A better solution : you add a new event in both lttng and lttv, and
> modify state.c to support your new event. The current event to brand
> thread is named "userspace.thread_brand". Look for this in LTTV to see
> all the sites that need to support the new event (there are very few).
> 
Thanks, but I want to avoid to modify too much ltt (I use an old version
for 2.6.27 and my modifications may be useless for upstream).

I added "trace_fs_exec(tsk->comm);" at the end of set_task_comm and now
the thread got the correct name :)


Matthieu

[ltt-dev] Tracing thread name

[Matthieu CASTET]

Matthieu CASTET a ?crit :
> Hi,
> 
> Mathieu Desnoyers a ?crit :
>> * Matthieu CASTET (matthieu.castet at parrot.com) wrote:
>>> Hi Mathieu,
>>>
>>> Mathieu Desnoyers a ?crit :
>>> Do you know if it is possible to patch my version to add such feature ?
>>>
>>> I saw that the name already change in the trace before/after an exec.
>>> How lltv get the new name ?
>>> With "fs.exec" tracepoint ?
>>> In that case I could fake a "fs.exec" tracepoint in set_task_comm.
>> A better solution : you add a new event in both lttng and lttv, and
>> modify state.c to support your new event. The current event to brand
>> thread is named "userspace.thread_brand". Look for this in LTTV to see
>> all the sites that need to support the new event (there are very few).
>>
> Thanks, but I want to avoid to modify too much ltt (I use an old version
> for 2.6.27 and my modifications may be useless for upstream).
> 
> I added "trace_fs_exec(tsk->comm);" at the end of set_task_comm and now
> the thread got the correct name :)
> 
BTW it is also interesting to get the name of the kernel threads
(created by kthread_create).
The current version of ltt show "kthreadd" for these threads.

The same solution than set_task_comm should solve the problem (comm is
set at the end of kthread_create).


Matthieu

PS: khelper thread are also annoying because they all got the same name.
May be it could be interesting to add extra info in the name.