Why is PCE not set in CR4?
Bruce M Simpson
bms at spc.org
Sat Oct 18 10:00:18 PDT 2003
On Wed, Oct 01, 2003 at 11:39:36AM +0200, Grumble wrote:
> I have read the perfmon documentation and source code. For several
> reasons, I do not think it is totally adequate in my situation.
> It was designed in 1996 with the Pentium Pro in mind, which,
> apparently, only has two performance counters:
> #define NPMC 2
> if (pmc < 0 || pmc >= NPMC) return EINVAL;
> Assume I get perfmon to work with my K7's 4 performance-monitoring
> counters. Since PCE is not set, I am not allowed to call RDPMC from
> ring 3. I have to make a system call, just to read the counters.
I've since read over perfmon and some notes on using performance monitoring
counters in "The Indispensable PC Hardware Book".
It looks to me as though perfmon *will* do what you want. There isn't
really any need to reinvent the wheel. If you want to configure *all* your
PMCs to read particular events, then the best way to do this is as follows:
Conditionalise the PMC allocation code in perfmon.c to use a boot-time
tunable, or an int, which is set by the identcpu.c code. Allocate the PMC
structures in perfmon.c at boot-time (or preferably module init time).
Then, add the necessary code to perfmon_init() and a new writectlXX()
function pertaining to the particular Athlon you're using.
> I will pay in terms of computation overhead to process a system
> call, instead of a single instruction. But more importantly, it will
> wreck the cache, and possibly the TLB.
> There is no point in monitoring an event if the monitoring tools
> disturb the environment too much.
Ignore the patch I sent previously. perfmon is i386 specific anyway, so
hacking perfmon.c is acceptable. What I would suggest instead is to add
two new ioctls to perfmon to do this.
PMIOGPCE get pce bit value on current CPU
PMIOSPCE set pce bit value on current CPU (if superuser)
This will allow you to set PMC enable on and off for the uniprocessor
case OK, and let you use RDPMC from ring 3. This is not valid for the
SMP case, however.
Unless you can achieve CPU binding (not affinity) with one of the current
scheduler(s) then reading the counters is likely to yield useless results
if your code spins across CPUs in an SMP system.
An IPI of some kind will be necessary if you want to tell all processors
to turn on their PCE bit at the same time. peter at freebsd.org is a good
guy to ask about this sort of thing.
I'd like to know how you're progressing with this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 167 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20031018/2cef4400/attachment.bin
More information about the freebsd-hackers