Can't get any significant number of vmlinux samples to show up.

I tried using oprofile 0.9.3 on Fedora 8, using a freshly compiled
2.6.24 kernel.

First, it seems that oprof_start (or something) misconfigured
the --kernel-range.  I changed that to what I believe is more proper
values by setting the start to 1000000 and the end to the last symbol
found in the /boot/System.map file.  This appeared to make oprofile
report lots of samples, except that it can't list them explicitly.

First, the PS listing:

root     18970  0.7  0.4  18768  9264 pts/0    S    18:29   0:00 oprof_start
root     19313  0.8  0.0   3384  1784 ?        S    18:30   0:00 /usr/bin/oprofiled --session-dir=/var/lib/oprofile
--separate-lib=1 --separate-kernel=1 --separate-thread=0 --separate-cpu=0
--events=GLOBAL_POWER_EVENTS:29:0:100000:1:1:1, --vmlinux=/boot/vmlinux-2.6.24 --kernel-range=1000000,c143f000

[root <at> lf1002-155 ~]# opreport
CPU: P4 / Xeon with 2 hyper-threads, speed 3000.36 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01
(mandatory) count 100000
GLOBAL_POWER_E...|
   samples|      %|
------------------
   2056094 86.0331 btserver
         GLOBAL_POWER_E...|
           samples|      %|
         ------------------
           1580191 76.8540 vmlinux-2.6.24
            330083 16.0539 btserver
            106325  5.1712 e1000

Re: [patch 0/7] Oprofile AMD IBS support

John Levon wrote:

> Is there any way you can send it inline but not mangled? It's harder
> for me to review in a tar file. If not, that's fine.

Here's my attempt at inlining the patches. (Patches 2, 3, and 6 have
been left out because they are large.)

diff -uprN -X dontdiff oprofile-cvs-original/utils/opcontrol oprofile-cvs-ibs/utils/opcontrol
--- oprofile-cvs-original/utils/opcontrol	2008-01-28 16:05:29.000000000 -0600
+++ oprofile-cvs-ibs/utils/opcontrol	2008-01-29 09:39:46.000000000 -0600
 <at>  <at>  -120,6 +120,15  <at>  <at>  do_help()
    --reset          clears out data from current session
    --save=name      save data from current session to session_name
    --deinit         unload the oprofile module and oprofilefs
+   --no-event       clear all events
+
+   --ibs-fetch=#count            enable AMD IBS Fetch sampling with maximum count.
+                                 Use 0 to disable IBS Fetch profiling.
+                                 ( Default = 250000, Min = 25000, Max = 1048575 )
+
+   --ibs-op=#count               enable AMD IBS OP sampling with maximum count.
+                                 Use 0 to disable IBS OP profiling.
+                                 ( Default = 250000, Min = 25000, Max = 1048575 )

    -e/--event=eventspec 

Re: JIT_SUPPORT: patch for version info of opagent library

Hi!

Due to our last discussion I have modified the implementation.

Just review again and give comments.

Kind regards,
Daniel

John Levon wrote:
> On Thu, Jan 31, 2008 at 05:20:50PM +0100, Daniel Hansel wrote:
> 
>> +__asm__(".symver op_major_version_1_0,op_major_version <at> OPAGENT_1.0");
>> +__asm__(".symver op_minor_version_1_0,op_minor_version <at> OPAGENT_1.0");
>> +
>> +int op_major_version_1_0(void)
>> +{
>> +	return 1;
>> +}
>> +
>> +int op_minor_version_1_0(void)
>> +{
>> +	return 0;
>> +}
> 
> I don't think this is necessary, you can just leave out the asm and do
> op_major/minor_version()
> 
> We only need this symver stuff when we have two symbols with the same
> name but different implementations. We haven't even released 1.0 yet, so

[PATCH] OProfile on Cell, profile stack code

When a program running on a Cell SPU needs to perform an operation such
as I/O the request is sent to the PPU.  In order to do this the runtime
functions generally call __send_to_ppe which creates a small code stub
on the stack and then jumps to the stub.  Since the stub's address does
not show up in the program's memory map OProfile would normally ignore
this address.  This change creates an artificial symbol
(__send_to_ppe(stack)) for Cell SPU profiles.  Addresses captured that
are not in the program's memory map are attributed to this symbol.

There was also another case in the code in op_bfd.cpp that an artificial
symbol was created with a FIXME note by it.  I changed that part of the
code to use the new boolean I added to op_bfd_symbol to be consistent.

Bob Nelson

Index: oprofile-0.9.3/libutil++/op_bfd.h
===================================================================
--- oprofile-0.9.3.orig/libutil++/op_bfd.h
+++ oprofile-0.9.3/libutil++/op_bfd.h
 <at>  <at>  -43,6 +43,7  <at>  <at>  public:

        /// ctor for artificial symbols
        op_bfd_symbol(bfd_vma vma, size_t size, std::string const & name);
+       op_bfd_symbol(bfd_vma vma, unsigned long fp, size_t size, std::string const & name);

        bfd_vma vma() const { return symb_value + section_vma; }
        unsigned long value() const { return symb_value; }
 <at>  <at>  -53,6 +54,7  <at>  <at>  public:
        void size(size_t s) { symb_size = s; }

[Fwd: Re: [patch 0/7] Oprofile AMD IBS support]

hi,

My colleague informed me that my previous mail did not reach the list. 
Thus I am re-sending it out. If you have received the email, sorry for 
the inconvenience.

Jason

-------- Original Message --------
Subject: Re: [patch 0/7] Oprofile AMD IBS support
Date: Wed, 30 Jan 2008 09:54:35 -0600
From: Jason Yeh <jason.yeh <at> amd.com>
To: John Levon <levon <at> movementarian.org>
CC: oprofile-list <oprofile-list <at> lists.sourceforge.net>
References: <479F9F1C.4090708 <at> amd.com> 
<20080129222405.GB31646 <at> totally.trollied.org.uk>

John Levon wrote:
> A whole bunch of this new code doesn't meet the coding standard. I know
> it's tedious but it really does need cleaning up before integration.

Sorry about that. I attached that tar.gz of the patches. I will work on 
the coding standard in the next version of the patch. Is 
"check_style.py" still being used to verify the coding standard?

> 
>> Three new options are added to opcontrol script. "--ibs-fetch=#count"
>> and "ibs-op=#count" enabl and specify the max count for IBS fetch and
>> op repectively. "--ibs-fetch=0" and --ibs-op=0" disable IBS.
>> "--no-event" is added to clear the current event selection in daemonrc.

Re: JIT_SUPPORT: patch for version info of opagent library

On Fri, Feb 01, 2008 at 03:33:09PM +0100, Daniel Hansel wrote:

> Due to our last discussion I have modified the implementation.

Looks good

thanks
john

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

oprofile error

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
oprofile-list mailing list
oprofile-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list

Re: [PATCH] Fix error check in Cell daemon code

Bob Nelson wrote:
> The function code_spu_ctx_switch is checking for 7 entries in the buffer
> to ensure that it has enough data for a context switch entry.  A context
> switch only generates 6 entries in the buffer so if it is the last thing
> in the buffer a "Dangling ESCAPE_CODE" error will be generated.
>
> Bob Nelson
>
> Index: oprofile-0.9.3/daemon/opd_spu.c
> ===================================================================
> --- oprofile-0.9.3.orig/daemon/opd_spu.c
> +++ oprofile-0.9.3/daemon/opd_spu.c
>  <at>  <at>  -56,7 +56,7  <at>  <at>  void code_spu_ctx_switch(struct transien
>  {
>         clear_trans_current(trans);
>
> -       if (!enough_remaining(trans, 7)) {
> +       if (!enough_remaining(trans, 6)) {
>   
Yes, this is correct.  Thanks for the patch, Bob.
John, I can add a Changelog entry and commit this if you would like

-Maynard
>                 trans->remaining = 0;
>                 return;
>         }
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> oprofile-list mailing list
> oprofile-list <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: [PATCH] Fix potential loop in opcontrol

Bob Nelson wrote:
> This patch fixes a hang that can occur when $SESSION_DIR is pointed to a network
> drive.  If the systems involved are not exactly synchronized then the file 
> timestamps can cause opcontrol to go into a loop waiting for the dump to complete 
> even though the dump is already done.
>
> Bob Nelson
>
> Index: oprofile-0.9.3/utils/opcontrol
> ===================================================================
> --- oprofile-0.9.3.orig/utils/opcontrol
> +++ oprofile-0.9.3/utils/opcontrol
>  <at>  <at>  -1430,26 +1430,24  <at>  <at>  do_dump_data()
>
>         if test "$KERNEL_SUPPORT" = "yes"; then
>                 # find current time
>   
Obsolete comment ^^^
> -               TMPFILE=`mktemp /tmp/oprofile.XXXXXX` || exit 1
>                 if ! test -w $MOUNT/dump; then
>                         if test `id -u` != "0"; then
>                                 echo "You must be root to dump with this kernel version"
>                                 exit 1
>                         fi
>                 fi
> +               rm -f "$SESSION_DIR/complete_dump"
>   
Whenever the daemon completes a read of the buffer, it calls 
opd_do_samples and will end up writing to the complete_dump file.  So 
what happens here if you're removing the file as the daemon has it open 
for write?  I think it's OK, as the complete_dump file would just get 
written out as a new file.  We would exit immediately from the while 
loop below, but I don't see a problem with that either.
>                 echo 1 > $MOUNT/dump
>                 # loop until there is a file to check and
>                 # the modification data of $MOUNT/dump after TMPFILE
>   
Change this comment ^^^ to reflect code change
> -               while [ \( ! -e "$SESSION_DIR/complete_dump" \) -o \( "$TMPFILE" -nt "$SESSION_DIR/complete_dump" \) ]
> +               while [ \( ! -e "$SESSION_DIR/complete_dump" \) ]
>                 do
>                         if test ! -d "/proc/$OPROFILED_PID"; then
> -                               rm $TMPFILE
>                                 echo "dump fail: either daemon died during last run or dies during dump" >&2
>                                 return 1
>                         fi
>                         sleep 1;
>                 done
> -               rm $TMPFILE
>         else
>                 echo 1 > $MOUNT/dump
>                 # HACK !
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> oprofile-list mailing list
> oprofile-list <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: oprofile error

john bryant wrote:
> Hi,
>
> I am trying to configure oprofile and getting following error when i 
> start oprofile:
>
> /usr/local/bin/opcontrol: line 1082: echo: write error: Invalid argument
John, you don't say what version of OProfile you're running, but this 
sounds like a bug that was fixed about a year ago.  The fix was included 
in the latest 0.9.3 release.  If you're running 0.9.3, then this 
obviously isn't the same problem.  But if you're using an older version 
of OProfile, check out the following posting on the oprofile-list:
    http://marc.info/?l=oprofile-list&m=116605528426963&w=2

Regards,
-Maynard
> Using 2.6+ OProfile kernel interface.
> Reading module info.
> Using log file /var/lib/oprofile/oprofiled.log
> Daemon started.
>
> oprofiled.log indicated it started. Any help will be great.
>
> -John
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> oprofile-list mailing list
> oprofile-list <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
>   

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/