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

List:       oprofile-list
Subject:    XML output.
From:       Rob Fowler <rjf () rice ! edu>
Date:       2005-12-21 6:54:05
Message-ID: 43A8FC0D.2050205 () rice ! edu
[Download RAW message or body]

 >Date: Tue, 20 Dec 2005 18:21:00 -0800
 >From: Andrew Grover <andy.grover@gmail.com>
 >To: John Levon <levon@movementarian.org>
 >Subject: Re: Would it be helpful to oprofile users if oprofile can generate 
XML >format output?
 >cc: Yao Fei Zhu <walkinair@cn.ibm.com>, oprofile-list@lists.sourceforge.net
 >
 >On 11/28/05, John Levon <levon@movementarian.org> wrote:
 >
 >> On Tue, Nov 29, 2005 at 03:27:25AM +0800, Yao Fei Zhu wrote:
 >>
 >>
 ><>>> > Another advantage I think of XML output file is that it has wider usage
 >>>> > than archive created by oparchive.
 >
 >>
 >> Simple answer: yes, we really want this.
 >
 >
 >Yes yes yes...
 >
 >-- Andy

Our group currently has internal versions of oprofile  and a conversion tool
intended to make oprofile use reasonable by non-root users and
to get data into the XML format used by HPCToolkit.  We're doing internal
testing and documentation right now, but it should be ready to be propagated
back to the community in a couple of weeks.

All of the oprofile tools that need it have been modified to take a 
--session-dir argument.   This causes the demon to write things into more useful
locations than /var.  There are two reasons we can't just oparchive.  First,
on a cluster with diskless nodes, /var is in a RAM file system and memory is
precious, so the outputs need to be directed to some network-mounted file
system.  Second, even on clusters with disks on compute nodes, the user usually 
doesn't have access to the node, much less /var on the local disk, after his job 
has run. Thus, we need to put the data immediately in a place where a non-root 
user can analyze it.

Conversion to XML is done is two stages. We wrote a converter, currently with
the unimaginative name "ophpctoolkit", that reads oprofile binary archive and
outputs an equivalent in the binary format generated by hpcrun.  The second
stage uses hpcprof  to extract sample files in the XML format that we use for
profiles.  We didn't want to duplicate any of the functionality of hpcprof into
ophpctoolkit because this simplifies our maintenance problem

Used "by hand" by an ordinary user, a session might look like:
   1> mkdir /scratch/myrun
   2> sudo opcontrol --session-dir=/scratch/myrun --start --event= ...
   3> myprogram  <myprogram's args>
   4> sudo opcontrol --shutdown
   5> opreport --session-dir=/scratch/myrun
   6> ophpctoolkit --session-dir=/scratch/myrun/  -o myworkingfile
   7> hpcprof -p myprogram myworkingfile >myprogram.pxml
   8> hpcprof -p vmlinux myworkingfile >vmlinux.pxml
   9> hpcprof -p some_program_myprogram_spawned myworkingfile >foo.pxml
   8>  ... and the rest of the hpctoolkit stuff.

Notes:

We intend that steps 1-4 would usually be done by a wrapper script
that checks permissions and ensures that the system is left in a reasonable
state when the user is done.  Note that because oprofile will capture
data from both the user's program and from everything "competing" with it,
this is suitable only for development systems with a "friendly"
set of users.

On a cluster, a wrapper would be executed by the cluster scheduler running
as root and it would do the necessary permission checks, create and use
sub-directory for each node, and  chown and chmod the output directories to be 
owned by the user.

Instead of just one program, the "payload" of the wrapper would often be a
script that executes a complicated workflow, maybe by starting up an
interactive sub-shell.

Running opreport here is not necessary, but is an example of good practice.
It gives the user an idea of which images, in addition to his own
program,  significantly impacted performance.  Some of these may have
been part of the workflow.  Some may be competing activities that impacted
the execution.  This is a big advantage of oprofile over hpcrun.

The sequence of hpcprof executions extracts an XML file for each of these
images. Everything from line 7 onward would typically be embedded in a
hpctoolkit script.  For example, pointing hpcquick at myworkingfile extracts
XML for all of the images in in myworkingfile,  so we can suck the entire
oprofile archive up into our toolchain for analysis.

Because profiles can be huge, we have a pretty lean XML format for profile data.
See
http://hipersoft.rice.edu/hpctoolkit/documentation/HPCToolkit/doc/dtd_profile.html
for a description.

-- Rob Fowler


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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]