Hello Erik,
On Tue, Jul 15, 2008 at 1:37 PM, Erik Junberger <[EMAIL PROTECTED]> wrote: > Hello perfmon devolopers and users. > > I am currently working on my thesis project, which in short is to > integrate sampling capabilities into a commercial Java virtual machine. > This is achieved via the perfmon2 kernel interface and libraries. The > samples obtained is then used to make various dynamic optimizations. > The idea is to use one system-wide context per CPU to measure last-level > cache misses using PEBS. On buffer overflow, the PEBS buffer will be > read and aggregated in a data structure for further analysis by another > thread. > I just want to warn you that not ALL events support PEBS. The LAST_LEVEL_CACHE_MISSES does not support PEBS. You need to look at the example in libpfm/examples/x86/smpl_core_pebs.c > I have managed to implement this by looking at the examples supplied > with perfmon. I can create the contexts, program them, bind them to a > CPU and start monitoring without any problems. The values i receive > however are a little bit strange, and I wonder if anyone has a clue of > what might be going on. > I assume you've looked at examples/x86/smpl_pebs_core.c. The important trick is about PFM_REGFL_NO_EMUL64 on the PMC controlling the counter. > If I for instance set the /reg_value, reg_long_reset, reg_short_reset/ > and /pfm_pebs_core_smpl_arg_t.cnt_reset/ to -10000 (on pmd0), the values > are initially set correctly. Every time pmd0 wraps around however, the > lower 32-bits of pmd0 will be set to 0, and the upper 32 to 1. This > effectively means that I can't choose any other sampling period than 2³². > When I read the /pfm_ds_area_core_t.pebs_cnt_reset/ value, the correct > reset value is always returned, but this doesn't reflect reality. > With PEBS, you sampling value can only be 32-bit wide due to the wrmsrl() restriction that it can only modify the lower 32 bits. In fact you actually have 31-bits, bit 31 being the sign bit. > When PMD0 wraps around, no interrupt is generated, and no overflow is > registered in /pfm_pebs_core_smpl_hdr_t.overflows/. /pebs_index /is not > incremented either. > With PEBS, there is not interrupt until the buffer fills up. That's the whole idea. Amortize the cost of taking the interrupt over a large number of samples. But even though the PMC is set not to interrupt, the CPU will catch the overflow and micro-code will write a sample in the buffer. You'll only get an overflow once the buffer fills up, i.e., when the current position = threshold. After a sample is recorded, the micro-code reloads the counter with the cnt_reset value. That field is never actually modified by HW. > I have tried a lot of setup combinations in order to get this to work, > but nothing has worked. PEBS monitoring on a per-thread basis works > fine, so I don't think there is anything wrong with my system. I have > tried this both with a 2.6.24 and 2.6.25 kernel versions, with > libpfm-3.3 and 3.4 respectively. > I have tried this using pfmon in system-wide mode: $ pfmon --smpl-ignore-pids --system-wide --cpu-list=0 --smpl-module=pebs -einstructions_retired --long-smpl-periods=240000000 --pin-command my_test_program What happens on your system with this? ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
