> A little over a year ago I described a method by which you could do lazy
> switching of the counters -- to avoid futzing with the MSRs on every
> schedule. I can't find my message right now...
Found it in the November '97 lkml archives.
> You only need 32-bit previous because no events can happen more than 2^32
> in one schedule (this used to be true).
I belive so too. Suppose a 550MHz PIII genererates $2^{30}$ events per second.
That still allows up to 4 seconds between each switch_to(), which should be safe.
> And you only need to modify the event registers if the task you're
> switching to is trying to sample a different event.
Is a WRMSR to an evntsel or perfctr MSR so expensive that this is a problem?
I had just assumed a WRMSR only takes a few cycles..
> If you still want rdpmc you can leave it as a trap to kernel and simulate
> it with a read from total.
No need to trap. (That'd be so awful that people should just do a syscall
instead.) I allow the user to register a user-space buffer with the driver.
At process resumption, I copy the counter state to this buffer. (Technique
stolen from sparc64's sys_perfctr() implementation.) The user executes
RDPMC and RDTSC, retrieves the "base" values from the buffer, and then
computes the current "virtual" 64-bit values. This should permit people
to bracket single procedure bodies or basic blocks with sampling code
without too much overhead.
I'll probably do this with mmap instead, as soon as I've figured out how...
> The win is that you only need to write MSRs when you've got more than one
> task using the counters. You avoid the need to zero the counters.
If I don't zero the counters I still have to read them in order to know what
"previous" is. So is it a big win to do two RDPMC instead of two WRMSR?
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/