Ok I wrongly interpreted one of your previous answer and my confusion comes from there. Sorry. UNCORE events can't be used to sample on IP, but of course the MEM_INST_RETIRED.LATENCY_ABOVE_THRESHOLD event used by perf mem is not an UNCORE one.
Thanks Manu 2014/1/8 Manuel Selva <selva.man...@gmail.com>: > Thanks. > > I get the point about sampling, but my question was more about the > sources of memory accesses. In previous answer, you told me that the > PERF_SAMPLE_IP field is filled with "the IP of a random core on the > socket that happens to read the uncore registers", so my last question > is about the result presented by perf mem report tool. > > This tool (like perf report) reports a Symbol and a Shared Object > colums. I am thus wondering how can the entries in these columns be > correct if the IP for each sample is wrong ? > > Manu > > 2014/1/7 Andi Kleen <a...@firstfloor.org>: >> Manuel Selva <selva.man...@gmail.com> writes: >> >> >>> The perf mem record tool use the >>> MEM_INST_RETIRED.LATENCY_ABOVE_THRESHOLD which I guess belongs to the >>> memory PEBS events you mentionned (isn't it ?) is reporting >> >> Yes. >> >>> information about the sources of the events. it seems that for this >>> purpose the IP information is used, does it mean that what perf mem >>> reports can be wrong because of the random IP selection mechanism you >>> mentionned ? >> >> The CPU can theoretically execute billions of loads/stores every second. >> There is no way any reporting mechanism can keep up with that. >> So the only thing you can do is to sample (only collect >> every N operations), with a fairly large period. >> >> -Andi >> >> -- >> a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
