[lkml]   [2009]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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;

    if (pc->index) {
    count = pmc_read(pc->index - 1);
    count += pc->offset;
    } else
    goto regular_read;

    } while (pc->lock != seq);

    We don't see the hole you are referring to. The sequence lock
    ensures you get a consistent view.

     \ /
      Last update: 2009-06-22 13:55    [W:0.036 / U:8.708 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site