On Thu, Sep 1, 2011 at 3:29 PM, stephane eranian <eran...@googlemail.com> wrote: > On Thu, Sep 1, 2011 at 3:06 PM, Ryan Johnson > <ryan.john...@cs.utoronto.ca> wrote: >> On 01/09/2011 1:55 AM, stephane eranian wrote: >>> On Thu, Sep 1, 2011 at 1:07 AM, Corey Ashford >>> <cjash...@linux.vnet.ibm.com> wrote: >>>> On 08/25/2011 07:19 AM, stephane eranian wrote: >>>>> Hi, >>>>> >>>>> Sorry for late reply. >>>>> >>>>> The current support for mmaped count is broken on perf_event x86. >>>>> It simply does not work. I think it only works on PPC at this point. >>>> Just as an aside, you can access the counter registers from user space >>>> on Power (aka PPC) machines, but because the kernel is free to schedule >>>> the events onto whatever counters that meet the resource constraints, >>>> it's not at all clear which hardware counter to read from user space, >>>> and in fact, with event rotation, the counter being used can change from >>>> one system tick till the next. >>>> >>>> If you program a single event, you can be guaranteed that it won't move >>>> around, but you still will have to guess or somehow determine which >>>> hardware counter is being used by the kernel. >>>> >>> Yes, and that's why they have this 'lock' field in there.It's not really a >>> lock >>> but rather a generation counter. You need to read it before you attempt to >>> read and you need to check it when you're done reading. If the two values >>> don't match then the counter changed and you need to retry. And changes >>> means it may have moved to a different counter. >> This protocol is actually documented pretty well in >> <linux/perf_event.h>, too. Read the lock, read the index, read hw >> counter[index-1], read lock again to verify. >> >>> But the key problem here is the time scaling. In case you are multiplex >>> you need to be able to retrieve time_enabled and time_running to scale >>> the count. But that's not exposed, thus it does not work as soon as you >>> have multiplexing. Well, unless you only care about deltas and not the >>> absolute values. >> Doesn't perf_event_mmap_page expose both those, also protected by the >> generation counter? Or are you saying the kernel doesn't actually update >> those fields right now? >> > Yes, it does. I am not sure they're updated correctly, though. > I have not tried that in a very long time. > Did you manage to make libpfm4's self_count program work correctly? Even by just looking at the raw count coming out of rdpmc?
I think there are issues with hdr->offset, i.e., the 64-bit sw-maintained base for the counter. >> Ryan >> >> >> ------------------------------------------------------------------------------ >> Special Offer -- Download ArcSight Logger for FREE! >> Finally, a world-class log management solution at an even better >> price-free! And you'll get a free "Love Thy Logs" t-shirt when you >> download Logger. Secure your free ArcSight Logger TODAY! >> http://p.sf.net/sfu/arcsisghtdev2dev >> _______________________________________________ >> perfmon2-devel mailing list >> perfmon2-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/perfmon2-devel >> > ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
