Messages in this thread | | | Date | Mon, 22 Jun 2009 13:52:39 +0200 | From | Ingo Molnar <> | Subject | Re: I.5 - Mmaped count |
| |
> 5/ Mmaped count > > It is possible to read counts directly from user space for > self-monitoring threads. This leverages a HW capability present on > some processors. On X86, this is possible via RDPMC. > > The full 64-bit count is constructed by combining the hardware > value extracted with an assembly instruction and a base value made > available thru the mmap. There is an atomic generation count > available to deal with the race condition. > > I believe there is a problem with this approach given that the PMU > is shared and that events can be multiplexed. That means that even > though you are self-monitoring, events get replaced on the PMU. > The assembly instruction is unaware of that, it reads a register > not an event. > > On x86, assume event A is hosted in counter 0, thus you need > RDPMC(0) to extract the count. But then, the event is replaced by > another one which reuses counter 0. At the user level, you will > still use RDPMC(0) but it will read the HW value from a different > event and combine it with a base count from another one. > > To avoid this, you need to pin the event so it stays in the PMU at > all times. Now, here is something unclear to me. Pinning does not > mean stay in the SAME register, it means the event stays on the > PMU but it can possibly change register. To prevent that, I > believe you need to also set exclusive so that no other group can > be scheduled, and thus possibly use the same counter. > > Looks like this is the only way you can make this actually work. > Not setting pinned+exclusive, is another pitfall in which many > people will fall into.
do { seq = pc->lock;
barrier() if (pc->index) { count = pmc_read(pc->index - 1); count += pc->offset; } else goto regular_read;
barrier(); } while (pc->lock != seq);
We don't see the hole you are referring to. The sequence lock ensures you get a consistent view.
| |