Hello Roland,
On Jan 24, 2008 11:13 AM, Roland McGrath <[EMAIL PROTECTED]> wrote:
> > 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? ;-)
>
Okay, I will give it a try for 2.6.24. As for perfmon, I am hoping to
start pushing
some bits and pieces into 2.6.25. OTOH, there is a lot of things in flux at the
moment, utrace vs. ptrace, BTS, some hrtimer stuff, Power. Then I have to
look at some of the points people raised on the last LKML discussion regarding
versioning of the interface. Busy busy, not counting I have started a
new job....
