* Nils Carlson ([email protected]) 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 > [email protected] > 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
