BruceSong wrote:
>
> Hi Maynard,
>
> I retry according to your comments, but it still does not work. Please see
> the following steps:
>
> [brucehuang@...]$ sudo opcontrol --init
> [brucehuang@...]$ sudo opcontrol --reset
> [brucehuang@...]$ echo
>> /var/lib/oprofile/samples/oprofiled.log
> [brucehuang@...]$ sudo opcontrol --start
> Using 2.6+ OProfile kernel interface.
> Using log file /var/lib/oprofile//samples/oprofiled.log
> Daemon started.
> Profiler running.
> [brucehuang@...]$ sudo opcontrol --dump
So, you're dumping out the samples right after doing --start? Doesn't seem like you've done anything to to get samples yet. Here are the steps for profiling:
1. opcontrol --init
2. opcontrol --reset
3. opcontrol --setup (e.g., set a vmlinux file, set the event(s) to profile -- this only needs to be done the first time, in case you want to run these steps again to collect another profile with same profiling parameters.)
4. opcontrol --start
5. Run your application, which needs to run long enough for some samples to be taken.
6. opcontrol --dump | --stop | --shutdown
Any of these three options above will cause samples to be flushed to the file system.
--dump: profiling continues
--stop: profiling stops, but userspace daemon is still alive, thus, profiling can
be quickly restarted with '--start'
--shutdown: profiling stops AND userspace daemon is ended. If you want to change
profiling parameters (like changing the event to profile on), you must
shutdown the daemon and restart it with --start in order for it to pick up
the new parameters.
7. opreport
-Maynard
> [brucehuang@...]$ ls -ltr
> /var/lib/oprofile/samples/
> total 16
> drwxr-xr-x 3 root root 4096 Jun 23 14:14 aaa
> drwxr-xr-x 4 root root 4096 Jun 25 10:40 tmp
> drwxr-xr-x 4 root root 4096 Jun 25 10:55 current
> -rwxrwxrwx 1 root root 67 Jun 25 10:56 oprofiled.log
> [brucehuang@...]$ sudo opcontrol --status
> Daemon running: pid 7646
> Event 0: CPU_CLK_UNHALTED:500000:0:1:1
> Separate options: library
> vmlinux file: none
> Image filter: none
> Call-graph depth: 0
> [brucehuang@...]$ opreport --verbose=all
>
>
> Overflow stats not available
> Archive:
> Matched sample files: 0
> profile_classes:
> event:
> cpuinfo:
>
> error: no sample files found: profile specification too strict ?
> [brucehuang@...]$ sudo opcontrol --shutdown
> Stopping profiling.
> Killing daemon.
> [brucehuang@...]$ more
> /var/lib/oprofile/samples/oprofiled.log
>
> oprofiled started Fri Jun 25 10:56:03 2010
> kernel pointer size: 4
>
> Fri Jun 25 10:59:15 2010
>
>
> -- OProfile Statistics --
> Nr. sample dumps: 6
> Nr. non-backtrace samples: 45735
> Nr. kernel samples: 19807
> Nr. lost samples (no kernel/user): 0
> Nr. lost kernel samples: 0
> Nr. incomplete code structs: 0
> Nr. samples lost due to sample file open failure: 0
> Nr. samples lost due to no permanent mapping: 169
> Nr. event lost due to buffer overflow: 0
> Nr. samples lost due to no mapping: 37
> Nr. backtraces skipped due to no file mapping: 0
> Nr. samples lost due to no mm: 551
>
> ---- Statistics for cpu : 1
> Nr. samples lost cpu buffer overflow: 0
> Nr. samples received: 51942
> Nr. backtrace aborted: 0
>
> ---- Statistics for cpu : 0
> Nr. samples lost cpu buffer overflow: 0
> Nr. samples received: 35983
> Nr. backtrace aborted: 0
> oprofiled stopped Fri Jun 25 10:59:15 2010
>
>>From oprofiled.log, we can see it have achieved to get samples information
> successfully, but it does not work when using "opreport", why?
>
> I am very confused by this issue. Any help is appreciated.
>
> Thanks!
> Bruce
>
>
>
> Maynard Johnson wrote:
>>
>> On 06/24/2010 5:22 AM, BruceSong wrote:
>>>
>>> Hi Maynard,
>>>
>>> I find some information in internet, and recompile the oprofile using the
>>> latest binutils package, especially with the latest libbfd.a. Now it
>>> works.
>>>
>>> But sometimes, when I do some attempt, such as:
>>> sudo opcontrol --event=CPU_CLK_UNHALTED:100000:0:1:1, or other
>>> configuration. And then using opreport, it does not work.
>>>
>>> For example:
>>> [brucehuang@...:~]$ sudo opcontrol --init
>>>
>>> [brucehuang@...:~]$ sudo opcontrol --status
>>> Daemon not running
>>> Event 0: CPU_CLK_UNHALTED:100000:0:1:1
>>> Separate options: library
>>> vmlinux file: none
>>> Image filter: none
>>> Call-graph depth: 4
>>> [brucehuang@...:~]$ sudo opcontrol --start --verbose
>>
>> Do *NOT* use '--verbose' for normal profile runs. Use it *ONLY* for
>> debugging
>> problems. This adds a tremendous amount of overhead to the oprofile
>> daemon,
>> almost ensuring you'll get the "WARNING! The OProfile kernel driver
>> reports
>> sample buffer overflows" message.
>>
>>> Parameters used:
>>> SESSION_DIR /var/lib/oprofile
>>> LOCK_FILE /var/lib/oprofile/lock
>>> SAMPLES_DIR /var/lib/oprofile/samples
>>> CURRENT_SAMPLES_DIR /var/lib/oprofile/samples/current
>>> CPUTYPE i386/core_2
>>> BUF_SIZE default value
>>> BUF_WATERSHED default value
>>> CPU_BUF_SIZE default value
>>> SEPARATE_LIB 1
>>> SEPARATE_KERNEL 0
>>> SEPARATE_THREAD 0
>>> SEPARATE_CPU 0
>>> CALLGRAPH 4
>>
>> Doing callgraph profiling also adds a lot of overhead, both in kernel and
>> userspace. Whereas your sampling interval of one sample per 100,000
>> CPU_CLK_UNHALTED events might be fine ordinarily, I suspect that's a bit
>> too
>> much when you're also doing callgraph profiling. For profiling on
>> cycles-based
>> events (like CPU_CLK_UNHALTED), you can easily get a statistically valid
>> profile
>> by setting the count value pretty high--in your case, you can probably go
>> up to
>> 500,000.
>>
>> If you're collecting a profile where you just want to see hotspots and
>> don't
>> *need* to see callgraph data, then be sure to set --callgraph=0 to reduce
>> or
>> eliminate buffer overflows.
>>
>>> VMLINUX none
>>> KERNEL_RANGE
>>> XENIMAGE none
>>> XEN_RANGE
>>> executing oprofiled --session-dir=/var/lib/oprofile --separate-lib=1
>>> --separate-kernel=0 --separate-thread=0 --separate-cpu=0
>>> --events=CPU_CLK_UNHALTED:60:0:100000:0:1:1, --no-vmlinux --image=none
>>> --verbose=all
>>> Events: CPU_CLK_UNHALTED:60:0:100000:0:1:1,
>>> Using 2.6+ OProfile kernel interface.
>>> Using log file /var/lib/oprofile/samples/oprofiled.log
>>> Daemon started.
>>> Profiler running.
>>>
>>> [brucehuang@...:~]$ opreport --verbose=all
>>>
>>>
>>> WARNING! The OProfile kernel driver reports sample buffer overflows.
>>> Such overflows can result in incorrect sample attribution, invalid sample
>>> files and other symptoms. See the oprofiled.log for details.
>>> You should adjust your sampling frequency to eliminate (or at least
>>> minimize)
>>> these overflows.
>>> Archive:
>>> Matched sample files: 0
>>> profile_classes:
>>> event:
>>> cpuinfo:
>>>
>>> error: no sample files found: profile specification too strict ?
>>>
>>> You can see that error happens, and also it shows one warning. So why
>>> error
>>> happens? And also i think sample frequency is not higher since i set
>>> 100000
>>> count. What should be done for this warning?
>>
>> Try my suggestions above and see if you get some good reports. You ask
>> what can
>> be done about this warning? Coincidentally, I just helped write an
>> article on
>> this subject, which you can find at:
>> https://www.ibm.com/developerworks/wikis/display/LinuxP/Handling+oprofile+sample+buffer+overflows
>>
>> Let me know if that article helps clarify how to respond to the buffer
>> overflow
>> message.
>>
>> -Maynard
>>>
>>> Thanks a lot!
>>> Bruce
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit. See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> oprofile-list mailing list
>> oprofile-list@...
>> https://lists.sourceforge.net/lists/listinfo/oprofile-list
>>
>>
>
|