[ltt-dev] [PATCH] Fix initial state bug

[compudj@krystal.dyndns.org (Mathieu Desnoyers)]

* Francis Giraldeau (Francis.Giraldeau at USherbrooke.ca) wrote:
> Mathieu Desnoyers <compudj at krystal.dyndns.org> a ?crit?:
>>> +/* get a given quark from lttng module enum value */
>>> +#define ltt_enum_quark(e, f, names)  
>>> (g_quark_from_string(names[ltt_event_get_unsigned(e, f)]))
>>
>> Please use a static inline rather than a preprocessor macro for this. It
>> comes with type checking and removes odd macro corner-cases.
>
> Ok, done.
>
>>> @@ -3503,11 +3538,9 @@ static gboolean enum_process_state(void  
>>> *hook_data, void *call_data)
>>>  				es->t = LTTV_STATE_MODE_UNKNOWN;
>>>  				es->s = LTTV_STATE_UNNAMED;
>>>  				es->n = LTTV_STATE_SUBMODE_UNKNOWN;
>>> -#if 0
>>>  				es->t = LTTV_STATE_SYSCALL;
>>>  				es->s = status;
>>>  				es->n = submode;
>>> -#endif //0
>>
>> Hrm ? you're leaving the unknown and then changing the state ? What for ?
>>
>> How do you know the thread is not in interrupt or trap ? (see comment
>> above)
>
> Double state change is obviously wrong, my mistake. I removed those  
> changes. As I understand, we don't know for sure the initial state from 
> the state dump. The actual initial process state is known at the first 
> occurrence of an event in the trace, isn't?

Partly, yes. And some state is known by a combination of the state dump
process listing and the fact that we wait for a "grace period" to occur
before we issue the "statedump_end" event. This ensures that a kernel
worker thread has run on every CPU on the system.

We should take time to discuss all this, ideally with Julien. This is
definitely not an easy problem. We might have to generate a few
synthetic workloads under tracing to figure out the scenarios we have to
deal with.

Thanks,

Mathieu

>
> Francis
>
>
>
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com