On Mon, Sep 14, 2009 at 2:26 PM, Godmar Back<god...@gmail.com> wrote: > Stephane, > > thank you very much for these answers. I'd like to follow up on only 2 items: > > On Mon, Sep 14, 2009 at 4:34 AM, stephane eranian > <eran...@googlemail.com> wrote: >>> >> If by virtualized you mean that perfmon2 allows per-thread monitoring, >> then the answer is yes. You can attach a monitoring session to a thread. >> As the thread is context switched in and out, the monitoring session (PMU >> state) is also saved and restored. > > Is the PMU state of the next thread, in fact, physically restored by > writing its last value into the PMC register? If that's the case,
Yes, this is what is happening. > wouldn't the approach be limited to read-write registers, so read-only > register such as the TSC could not be read per-thread? Was that not a > concern? That is true. However we can deal with certain read-only registers. For instance, on Intel Core i7, the last branch record feature uses a read-only register but we can work-around the issue by restoring the content of the LBR slightly different than how we saved it. TSC is not considered a PMU register. If you'd like to support it then you'd have to emulate a read-write register in SW on top of it. > >> Counts specific to that thread can be >> extracted via a system call. At some point, perfmon2 also had the >> ability to read the counts directly from user-space using a remapping >> trick. But that was abandoned to simplify the code. But the same trick >> perfctr uses could also be used. > > Can you elaborate on that? I had assumed that supporting direct, > low-overhead access for fine-grained self-monitoring is a must have > for any performance monitoring library. > Why did you feel it was expendable? This was at a time where people were complaining that the perfmon API was too complex. So I felt this was not a critical feature and could be added again later on if badly needed. It is not as trivial as it seems to do the remapping, you have to deal with a race condition with the counter overflowing and the thread being preempted. There are also security issues. Also note that in perfmon you can read multiple counters in on syscall, i.e., you can amortize the cost. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
