oprofile on D2plug

[Burt]

Having trouble getting oprofile working on my D2plug, hope someone can point me in the right direction.  Here is the error I am getting:

sudo opcontrol --init
cpu_type 'unset' is not valid
you should upgrade oprofile or force the use of timer mode

The /dev/oprofile/cpu_type file is indeed empty.

I rebuilt and installed the kernel to verify oprofile support was enabled (and to get a good vmlinux), the following settings were in the kernel .config file:

CONFIG_OPROFILE_MRVL_PJ4=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y

I configured oprofile 0.9.7 as follows:

./configure --with-linux=~/build/lsp/d2plug-linux-2.6.32.y/ --with-kernel-support --with-qt-dir=/usr/share/qt3

Where did I go wrong?  Any tips greatly appreciated.

[mentor]

I think you not add Marvell PJ4 event at opfrofile source

I have done it for you , attach zip file contain two version oprofile patch , one is for 0.9.5 another is for 0.9.7 , I think you uncompress it see the file name will know it

I also list how to make it for your reference

follow the procedure to build that
   $> sudo apt-get install gcc-4.1 cpp-4.1 g++-4.1
   $> sudo apt-get install libpopt-dev binutils-dev
   $> cd <oprofile folder>
   $> CC=gcc-4.1 CPP=cpp-4.1 CXX=g++-4.1 ./configure --with-kernel-support
   $> make
   $> sudo make install
   $> sudo opcontrol --init
   $> ophelp

[Burt]

Thanks for the help, your patch has fixed the issue!  Will try to do some profiling soon.

The output of my ophelp command is now:
  oprofile: available events for CPU type "ARM/Marvell PJ4 Core"
  ...

And:
  cat /dev/oprofile/cpu_type
  arm/mrvl_pj4

Much better!

[Burt]

I tried collecting some profile data today, but got no data.  Guessing something is still not configured properly.

Here are the steps I tried:

sudo opcontrol --deinit

sudo opcontrol --status
  Daemon not running
  Event 0: CPU_CYCLES:100000:0:1:1
  Separate options: library kernel
  vmlinux file: none
  Image filter: none
  Call-graph depth: 10

sudo opcontrol --init

sudo opcontrol --reset

sudo opcontrol --start --verbose
  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 arm/mrvl_pj4
  BUF_SIZE default value
  BUF_WATERSHED default value
  CPU_BUF_SIZE default value
  SEPARATE_LIB 1
  SEPARATE_KERNEL 1
  SEPARATE_THREAD 0
  SEPARATE_CPU 0
  CALLGRAPH 10
  VMLINUX none
  KERNEL_RANGE
  XENIMAGE none
  XEN_RANGE
  executing oprofiled --session-dir=/var/lib/oprofile --separate-lib=1 --separate-kernel=1 --separate-thread=0 --separate-cpu=0 --events=CPU_CYCLES:254:0:100000:0:1:1, --no-vmlinux --verbose=all
  Events: CPU_CYCLES:254:0:100000:0:1:1,
  Using 2.6+ OProfile kernel interface.
  Using log file /var/lib/oprofile/samples/oprofiled.log
  Daemon started.
  Profiler running.

<run test process>

sudo opcontrol --stop
  Stopping profiling.

opreport
  error: no sample files found: profile specification too strict ?

[mentor]

I think you start / stop too short

for my case, after start ,  perform cp cammand to copy vedio file, used toem to play vedio

after these than type stop, and used opreport , I could see some data

BTW , if your log save loaction , you don't have permession , also have problem , if this way ,try to used "--session-dir" parameter to chang record and report path
 

[Burt]

Thanks again!

I created a new directory in my users home dir and pointed oprofile at it:
  sudo opcontrol --session-dir=/home/ubuntu/pdata

Then ran the test as before, and  the report showed lots of data this time:
  opreport --session-dir=/home/ubuntu/pdata

I noticed that all the files in /home/ubuntu/pdata are owned by root, same as in /var/lib/oprofile.  Makes some sense as oprofile is started as root (using sudo).

Where does the permission problem come from?

[Burt]

Things were working well, then out of the blue things stopped working.  Same error when trying to generate a report:
  error: no sample files found: profile specification too strict ?

Tried rebooting, didn't help.  Makes me wonder what reallly got things working to begin with.

My ./root/.oprofile/daemonrc file:

SESSION_DIR=/home/ubuntu/pdata
CHOSEN_EVENTS_0=CPU_CYCLES:100000:0:1:1
NR_CHOSEN=1
SEPARATE_LIB=1
SEPARATE_KERNEL=1
SEPARATE_THREAD=0
SEPARATE_CPU=0
VMLINUX=none
IMAGE_FILTER=
CPU_BUF_SIZE=0
CALLGRAPH=20
XENIMAGE=none

Are folks using the same kernel as I am?
  Linux D2Plug 2.6.32.9-dove-5.4.2

[mentor]

I list what we do here, maybe it could help you

first all , I try more time at oprofile 0.95 version, not 0.97 , 0.97 is my base 0.95 modify than porting to 0.97, so if possible ,try 0.95 version first

I perform below command at console, sometimes I have see opreport show up can't find sample file, than I re-test 1-2 times , it will back to normal

sudo opcontrol --init  //if you second test you could used reset
sudo opcontrol --setup --no-vmlinux --event=CYCLE_COUNT:20000000
sudo opcontrol --start --session-dir=/home/ubuntu/<my save log folder>

export DISPLAY=:0.0 //if you used xtermal (I not give a try) , you don't type this
totem <vedio clip name> & //totem running at backgroud, await a while (almost 1 -2 min) ,this is my case, maybe not need to wait so long

sudo opcontrol --stop

opreport --session-dir=/home/ubuntu/<my save log folder>

[Burt]

I moved to oprofile version 0.9.5 and things appear to be much more reliable now.  Every once in a while no data is collected, but usually I get results.  (hope this lasts!)

Some of the settings I am using:
  Event 0: CPU_CYCLES:100000:0:1:1
  Separate options: library kernel
  vmlinux file: /home/ubuntu/build/lsp/d2plug-linux-2.6.32.y/vmlinux
  Image filter: none
  Call-graph depth: 0

And the steps that seem to work best for me:
  sudo opcontrol --init
  sudo opcontrol --reset
  sudo opcontrol --start --session-dir=/home/ubuntu/pdata
  <run tests>
  sudo opcontrol --dump
  sudo opcontrol --stop
  opreport --session-dir=/home/ubuntu/pdata
  sudo opcontrol --deinit

[mentor]

So... this is mean it work or it not work?

[Burt]

It is working!

Every once in a while it fails to collect data, but works on a re-test (you described the same sort of thing).