[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oprofile-list
Subject:    Re: Help determining cpu-buffer-size
From:       Maynard Johnson <maynardj () us ! ibm ! com>
Date:       2009-09-02 21:13:24
Message-ID: 4A9EDFF4.1090000 () us ! ibm ! com
[Download RAW message or body]

John Sasso wrote:
> I am using oprofile 0.9.5 on an Intel Core Duo system running Ubuntu 
> 9.04.  When profiling, I often get the following in opreport:
> 
> WARNING! The OProfile kernel driver reports sample buffer overflows.
> 
> My understanding is that this can be mitigated through --cpu-buffer-size 
>   in opcontrol.   What is the best way to determine this setting, or is 
> there a recommended setting?
The message also says the following:

    See the oprofiled.log for details.
    You should adjust your sampling frequency to eliminate (or at least minimize)
    these overflows.

The easiest thing to try is to lower your sampling frequency.  So if you're 
sampling on, say, every 50,000 CPU cycles, try sampling on every 100,000 cycles. 
You can also check the oprofiled.log and see how many overflows you're getting 
compared to the number of samples received.  If the percentage is very low 
(grabbing a number out of the air, say, less than 1%), you can probably safely 
ignore the warning message.  Since OProfile is a statistical profiler, the more 
samples you lose, the less valid the profile data.

The oprofile kernel drivers uses a two-level buffering scheme.  It uses a set of 
per-CPU buffers that samples are initially stored into, and then, periodically, 
copies the samples over to the main "event buffer" from which the userspace 
daemon reads.  When you look at the oprofiled.log, you'll see an initial group 
of OProfile Statistics that includes "Nr. event lost due to buffer overflow". 
This refers to the main event buffer.  Use the ratio of this field's value to 
that of the "Nr. non-backtrace samples" field to get the percentage overflow for 
that buffer. Then below that group of stats, you'll see a group for each CPU, 
with a "Nr. samples lost cpu buffer overflow".   Those are the per-CPU buffers. 
  Again, use the value of that field with the corresponding "Nr. samples 
received" for that CPU to get a percentage overflow for that CPU's buffer.

If you decide that adjusting sample frequency is not acceptable and you think 
the overflow rate is pretty high, then you can start playing with buffer sizes. 
  One tip:  If you're running on a busy multi-CPU system, try bumping up the 
main event buffer before messing with the cpu buffer size.  Then buffer 
watershed parameter should be adjusted as well.

-Maynard
> 
>     --john
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> oprofile-list mailing list
> oprofile-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oprofile-list



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
oprofile-list mailing list
oprofile-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
[prev in list] [next in list] [prev in thread] [next in thread]