> 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.
Having an engine attached with no event reports currently requested should add no overhead at all to the thread's normal execution. In fact, as long as you haven't lately done utrace_set_flags to request something, it should change no code path at all until the task gets passed to release_task. > Now, in which kernel version can I expect to have the utrace engine? > I am willing to try it out. It is available today in Fedora kernels, RHEL5 kernels, and in patches you can build yourself against upstream 2.6.23 or trunk that support several architectures (see http://redhat.com/~roland/utrace/). As to inclusion in an upstream kernel version, that is an ongoing story and you can read other threads on this mailing list about that. (In what upstream kernel version can I expect to have perfmon2, my good man? ;-) Thanks, Roland
