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

[Mathieu Desnoyers]

* Nils Carlson (nils.carlson at ericsson.com) wrote:
> Hi Robert,
>
> some answers below.
>
> On 05/17/2011 11:07 AM, Robert wrote:
>> Hi list,
>>
>> I am new to rcu/ust, and trying to figure out how to use ust to trace  
>> programs.
>> I don't know if it is right to post my problems here, since I didn't  
>> find any user mailing list.
>>
>> I am using ust-0.12 and urcu-0.5.4 under linux 2.6.24 ubuntu 8.04.4
>> There are 3 problems:
>>
>> 1. Why in source code like /marker.c/ file, some rcu related code are  
>> annotated?
>>   e.g.,
>> //* Make sure the call_rcu has been executed *//
>> ///ust// if (e->rcu_pending)/
>> ///ust//         rcu_barrier_sched();/
>>
>>    Then how ust do synchronization?
>>
> The reason these are commented out is that UST is a port of kernel code  
> to userspace, so a lot of code for the kernel is still present.
>
> As to how the synchronization works, Mathieu - can you answer this?

Yes. Instead of using rcu_barrier and rcu callbacks, we use the
synchronize_rcu big hammer to perform this synchronisation on the
execution path rather than to let the grace periods for various marker
operations execute in parallel. So this can cause a significant slowdown
on the marker enable/disable operation, but we'll refine that eventually
by porting the last version of the marker.c code available in the
kernel. Nils, since you want to keep markers.c in UST, it might be good
for you to look at my markers.c in lttng 0.19-stable to see how things
have evolved locking-wise since the last time UST have had its code
resynchronized with it.

>
>> 2. I am trying to trace some simple programs like pbzip2. I just find  
>> pthread_create call, and  insert trace_mark() into the function that  
>> is invoked by pthread_create. But then I get segmentation fault. I  
>> cannot figure out why.
>> The code is like:
>> /trace_mark(ust, newevent, "ret is %d", 100);/
>
> I don't see anything wrong with this. But maybe this version of UST was  
> not as stable as it should be. You can try checking out the latest one  
> from git if you want.

Nils, how about a 0.13 release ?

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


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