Model-Specific Register

[William Cohen]

Jason Yeh wrote:
> William Cohen wrote:
> 
>> Lorenzo Cavallaro wrote:
>>
>>> Hi,
>>>
>>> On Tue, Oct 10, 2006 at 03:46:29PM -0400, Frank Ch. Eigler wrote:
>>>
>>>>>   Beside that, I would like to measure (count) the number of 
>>>>> branches (call,
>>>>>   jmp, jcc, loop) executed so far by a given process while it's 
>>>>> executing in
>>>>>   user space. Do you think MSR (in particular) branch_retired 
>>>>> register could
>>>>>   be useful for what I'm trying to do?
>>>>
>>>>
>>>> Certainly.  Systemtap proper does not expose those registers yet, but
>>>> using e.g.  inline C code, it should be able to pull out such
>>>> information.
>>>
>>>
>>>
>>>    Cool. Any ideas (all the list, I mean :-)) on how to do it "from 
>>> scratch"?
>>>    Never played with MSR at all.
>>>
>>>
>>>>>   Moreover, I would like to save this register (or a combo of
>>>>>   registers) into the process task_struct since I would like to
>>>>>   keep this counter accross processes' context switch [...]
>>>>
>>>>
>>>> Check out the perfmon2 patches for the kernel.  Among other things, 
>>>> they
>>>> do this sort of context switch tracking.
>>>
>>>
>>>
>>>    Fine, thx! I'll check it out ASAP. :-)
>>
>>
>>
>> There is some example code in systemtap bz#909 using perfmon2 to setup 
>> the registers using Perfmon2. You can also take a look at the patches 
>> for the runtime to figure out how to access the perfmon hw:
>>
>> http://sources.redhat.com/bugzilla/show_bug.cgi?id=909
>>
>> Perfmon2 has support to keep count of events on a per-thread basis. So 
>> you might not need to do much in the way of modification to accomplish 
>> what you want.
>>
>> http://perfmon2.sourceforge.net/
>>
>> -Will
>>
>>
>>
> Does it make sense to have tabset for accessing the hardware performance 
> counters directly?  Perfmon2 is a good and complete framework, but it 
> seems like an overkill if I just want to collect simple stats using 
> systemtap.  What I have in mind is a tabset to access performance 
> counters which can be easily called from other stap scripts.  The tabset 
> will have to assume that the user knows the appropriate values for the 
> event select values and unit masks.
> What are the drawbacks of providing a tabset like this?
> Jason

Hi Jason,

Yes, Perfmon2 is overkill.

Currently oprofile, perfctr, and perfmon that all access the same performance 
monitoring hardware. It would be good to avoid having yet another piece of code 
written to access the performance monitoring hardware. There are some nice 
debugging features available in model specific hardware such as watchpoints, 
branch logs, and counters, making some kind of access available for systemtap 
would be good.

A very low level tapset that allow the script to set the bits in msr registers 
and read the registers would be possible. Have a wrapper that lists the perfmon 
registers for each particular processor. This would tie scripts to particular 
processors. There were need to be some check to make sure that script matched 
with the processor. Even when the script is running on the processor there are 
configurations that could cause problems, e.g. setting counter to interrupt 
every cycle. That would negate the systemtap safety checks.

What kind of event monitoring did you have in mind? Just count the number of 
events (e.g. instruction cache misses) from one point in the code to another? 
Would the counts be just the raw counts from the register or would this 
information need to be tracked on a per-thread basis? How good does the 
accounting of events need to be? Are the measurements guaranteed to fit in 
32-bit values or would the tapset need to handle 64-bit values? In the situation 
of an SMP machine would the measurements be always be between events on the same 
processor? Virtualized machines, e.g. running Xen?


-Will