Thanks for your reply.

Let's see whether I interpret your email correctly:
1. There is only one performance monitor counter (probably 1 per CPU?)
2. The PMC will increase by one after each CPU cycle.
If both were true, then it were like doing a time base sampling, and so a global reset count value should be fine for all event.

However, you mentioned it wouldn't make sense to have a global reset count.  Then, it sounds like there is a PMC per event.  But it wouldn't make sense either if #2 is true.

I must misunderstand your email.

Could you elaborate with an example that has 2 different reset count values for 2 different events?

Thanks in advance.

From: Maynard Johnson <>
To: Hei Chan <>
Cc: "" <>
Sent: Friday, September 28, 2012 8:19 AM
Subject: Re: operf's count setting

On 09/27/2012 05:53 PM, Hei Chan wrote:
> Hi,
> I finally got operf 0.98 running on my box.
> According to, the "count" means "the counter reset value".  What does it really mean?
The count value is the number of events that must occur before a sample is taken.  For example, on my Core 2 laptop, running 'operf <app>' results in the default event for this system, CPU_CLK_UNHALTED, to be used with a count of 100000.  This means that for every 100000 cycles, a sample is recorded.  So an app runtime of one second on my laptop having a clock speed of 2.53 GHz yields ~25,300 samples.  A performance monitor counter (PMC) is set up to generate a hardware interrupt after counting 100000 cycles.  Once that interrupt occurs, the PMC is reset to count up to 100000 again.

> When I run operf, and I get this warning:
> * * * * WARNING: Profiling rate was throttled back by the kernel * * * *
> The number of samples actually recorded is less than expected, but is
> probably still statistically valid.  Decreasing the sampling rate is the
> best option if you want to avoid throttling.
> opjitconv: Temporary working directory /home/hchan/cppzodiac-fix-test-workspace/test/Test HFIX/oprofile_data/tmp cannot be created.
> Exiting due to error: File exists
> JIT dump processing exited abnormally: 1
> So, couple questions:
> - How can I lower the sampling for all events?  According to doc, for operf, I can only specify the count for a specific event instead of all?
Not all events happen with the same frequency.  Some events happen quite often (like branch instructions executed), while others occur less often (like cache misses).  So it wouldn't make much sense to have an interface that set the reset count identically for all events.

> - It says that the folder cannot be created.  Do I need to remove the folder for each run?
That's a bug.  The opjitconv was not properly handling the space in your directory name (i.e, "Test HFIX").  I just fixed this upstream.  You could pull from our git repo to get the latest oprofile source or:
  1) Remove the space from your "Test HFIX" dir
  2) Manually delete the "tmp" dir in between each profiling run
  3) Edit your 0.9.8 source tree to add the fix I just made upstream.
    Open opjitconv/opjitconv.c and find the "rm_tmp" label.  You'll see the statement
                  sprintf(sys_cmd_buffer, "/bin/rm -rf %s", tmp_conv_dir);
    Add single quotes around the %s.

Thanks for reporting the bug.

> Thanks in advance.
> Cheers,
> Hei
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> _______________________________________________
> oprofile-list mailing list