Roland, Thanks for spending some time writing a simple code example. That helps me understand what's involved here.
On Jan 7, 2008 8:29 AM, Roland McGrath <[EMAIL PROTECTED]> wrote: > I don't think stateless calls like these are really what anyone wants to > be using. In real cases, you're going to be stopping and starting the > same thread many times, not just once. It should be far more efficient > and convenient to do utrace_attach once the first time you start dealing > with a thread, and just use utrace_set_flags calls to stop and start it > several times. You probably have your own data structures for this It is necessary to block the thread each time the monitoring tool wants to access its PMU state. So, yes the block, modify, unblock sequence would be needed multiple times. You would want to minize the cost of it as much as possible. So if it is possible to do part of the work once and keep it *without* execution overhead, then that would be great. There is indeed a data structure for the PMU state in which I could easily stick a pointer to the utrace data structure. > thread anyway, and you can hold the engine pointer there. If you do, you > may also have some synchronization for those data structures already. So > your callbacks can use whatever fits your code best, not just complete(). > (You just need to do utrace_detach before you abandon your data > structure, if that's before the thread gets passed to release_task.) > > If you are going for efficiency, then you probably actually want a more > asynchronous model anyway. You are ping-ponging context switches to wait > for it to stop, get notified and wake up, tweak the thread, wake it up, I do need something that is synchronous, i.e., when I invoke it the caller remains blocked until the monitored thread is off its CPU. The unblock call can be asynchronous. > and get back to running. With utrace, you can set up your data > structures with what needs to go into the thread and poke it with > UTRACE_ACTION_QUIESCE; it runs your callback, which looks at your data > structures, updates itself, and then clears QUIESCE, so it goes back to > running in its new condition. If your control logic needs to wait for > all threads to have done their self-updates, you can have the callback do > a count-down to wake you up before it goes back to running. > Yes, I would need something like that. Now, in which kernel version can I expect to have the utrace engine? I am willing to try it out. Thanks.
