[ltt-dev] why annotate some rcu related code?

[Nils Carlson]

On 05/17/2011 12:37 PM, Mathieu Desnoyers wrote:
> Nils, how about a 0.13 release ?

Tomorrow then. Almost time to go home here... :-)

/Nils

> By the way, one major thing I notice is still problematic in UST is that
> if the application is 32-bit and the consumer is 64-bit, these processes
> will disagree on the layout of the  mmap'd page exporting the buffer
> counters. This should eventually be fixed. It's not trivial though,
> because we want to export "unsigned long" counters that needs to be keep
> as large as possible whenever the architecture supports 64-bit atomic
> accesses (the larger these counters are, the less likely it is that we
> wrap-around and mess up the packet ordering without the consumer
> noticing). So some thought must be put in the process.
>
> I think it would be fair to enforce that, on a 64-bit system running
> some 64-bit binaries, the consumer daemon should be a 64-bit process (so
> a 32-bit daemon discovering a 64-bit process would fail). Now all we
> need to handle is the case where a 32-bit process is being consumed by a
> 64-bit daemon: we would need to export a header at the start of the
> shared counter page to let the consumer detect this, and use a union for
> the shared structure layout that lets the consumer access it through its
> 32-bit variant.
>
> Thanks,
>
> Mathieu
>
>>> 3. Actually I am not sure how to use libust. The manual as well as
>>> some other documents say that it is easy, just insert things like
>>> /trace_mark(ust, myevent, "firstarg %d secondarg %s", v, st);/
>>> into the code. But before that should I register or claim something?
>>> Specially, where can I find the definition of ust and myevent?
>>>
>> ust is a channel, the default channel for ust. A channel is a bit like
>> an IO-stream, think of stdin for instance. myevent is the name of the
>> marker itself. If you use ustctl list-markers<pid>  you will see the
>> markers that are present in your process.
>>
>> /Nils
>>
>>> These are silly questions, but I cannot solve them.
>>> Thanks in advance.
>>>
>>> -- robert
>>>
>> _______________________________________________
>> ltt-dev mailing list
>> ltt-dev at lists.casi.polymtl.ca
>> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
>