陳羿逞 \(Chuck\ | 1 Mar 13:04 2006
Picon

Re: Opreport Segmentation fault (MIPS DEC)


We have tried to tranfer sample results of target (MIPS-DEC) to x86 PC as
follows.
./opimport
/ram/oprofile/samples/current/\{root\}/nfs/oprofiled/\{dep\}/\{root\}/nfs/op
rofiled/TIMER.0.0.all.all.all --abi=x86_abi --output=TIMER.0.0.all.all.all
The transfer is done.
Then, copy TIMER.0.0.all.all.all to the corresponding path on x86 PC and use
opreport to analyze it.
However, we only get
"/ram/oprofile/samples/current/\{root\}/nfs/oprofiled/\{dep\}/\{root\}/nfs/o
profiled/TIMER.0.0.all.all.all Invalid Argument" error message.

Moreover, we do one more test of tranferring the x86 sample results to
itsself to see if opreport can show the statistics correctly.
We collect the sampling on x86 via opcontrol and everything is fine with
opreport.
Then, we do a tranfer with parameter '-f '.
./opimport
/ram/oprofile/samples/current/\{root\}/nfs/oprofiled/\{dep\}/\{root\}/nfs/op
rofiled/TIMER.0.0.all.all.all --abi=/ram/oprofile/abi
          --output=/ram/oprofile/samples/current/\{root\}/nfs/oprofiled/\{de
p\}/\{root\}/nfs/oprofiled/TIMER.0.0.all.all.all -f
Finally, we got another error message "./opreport error: oprofpp: samples
files version mismatch, are you running a daemon and post-profile tools with
version mismatch ?"

Is there something wrong in our test ?

Could you guys kindly tell us how to tranfer sample results between two
(Continue reading)

Andreas Krebbel | 1 Mar 13:39 2006
Picon

[PATCH] opcontrol: Save kernel-range and xen_range args to setup file

Hi,

the attached patch makes opcontrol save the arguments passed via --kernel-range
into the setup file. If the --xen parameter is present the range is saved as
XEN_RANGE otherwise as KERNEL_RANGE.

Bye,

-Andreas-

2006-03-01  Andreas Krebbel  <krebbel1 <at> de.ibm.com>

	* utils/opcontrol: (do_save_setup): Save KERNEL_RANGE and XEN_RANGE 
	values into setup file.
	(do_load_setup): Print KERNEL_RANGE, XENIMAGE and XEN_RANGE values in
	verbose mode.

--- oprofile/utils/opcontrol.orig	2006-03-01 13:13:55.000000000 +0100
+++ oprofile/utils/opcontrol	2006-03-01 13:26:24.000000000 +0100
 <at>  <at>  -344,7 +344,13  <at>  <at>  do_save_setup()
 		echo "NOTE_SIZE=$NOTE_SIZE" >> $SETUP_FILE
 	fi
 	echo "CALLGRAPH=$CALLGRAPH" >> $SETUP_FILE
+ 	if test "$KERNEL_RANGE"; then
+ 	        echo "KERNEL_RANGE=$KERNEL_RANGE" >> $SETUP_FILE
+ 	fi
 	echo "XENIMAGE=$XENIMAGE" >> $SETUP_FILE
+ 	if test "$XEN_RANGE"; then
+ 	        echo "XEN_RANGE=$XEN_RANGE" >> $SETUP_FILE
+ 	fi
(Continue reading)

Maynard Johnson | 1 Mar 16:19 2006
Picon

Re: Proposed XML schema for opreport -X option

Rob Fowler wrote:

>
>>
>> On Mon, Feb 27, 2006 at 05:53:44PM -0600, Maynard Johnson wrote:
>>
>>> Maynard Johnson wrote:
>>> Ping.  Has anyone had any time to look at this?  John, did I answer 
>>> your questions with the revisions I made?
>>
>>
>> I just don't have the time to look at this right now :(
>>
>> john
>>
>>
>>
>
>
> I've been meaning to send a reply to this, to the discussion
> about the API (C: yes, C++: a nightmare of compatibility issues),
> and reply to a message from John with questions about about design 
> decisions I described in my Dec 21 2005 message to this list. I
> will try to discuss this at length next week.
>
> Unfortunately, I've been swamped in other stuff and will

It must be contagious.  The swamp is up to my chin, too.  :-)

> be for at least another week.   In the interest of timeliness,
(Continue reading)

Hallale Venkat-AVH010 | 6 Mar 07:14 2006

Kernel Patch for 2.4.16 version and for MIPS32 arch

Hi All,
    I would like to know how to get the kernel patch of oprofile for 2.4.26 version and for MIPS32 architecture. Any pointers to kernel patch of oprofile for MIPS32 architecture will be a great help. I had gone through the FAQ, in that it has been mentioned that " OProfile ports for IA-64, AMD64, ARM, Alpha, PA-RISC, sparc64, s390, and ppc64 are all in various stages of support, mostly only on 2.6 kernels. "
 
But is there any patch available for 2.4.26 kernel for MIPS32 architecture.
 
Thanks in advance.
Regards,
Venkat Hallale
Ph : +91 80 5136 4340
 
Junichi Uekawa | 6 Mar 15:40 2006
Picon

Re: Proposed XML schema for opreport -X option

Hi,

> > Our approach is not to extract everything to XML.  Even
> > with the lean XML format for profile data, there is still
> > a substantial dilation in the size of the data.   We don't
> > want to do this to every executable image on thousands of
> > nodes of a huge cluster.  Hence, we wrote a tool
> > that extracts detailed profiles only for designated images.
> 
> My intention with the proposed schema design is that it would be 
> flexible enough to include as little or as much as what the user asks 
> for in their profile spec passed into opreport. 
> 
> Thanks for the constructive comments. 

I have not yet had the time to fully review your schema, but I have my
concerns that a full XML output might be too big in size for practical
usage. Do you have an example XML output for a system under load, or
an estimate over size? 

XML processing isn't free, if it's going to take ~10 seconds on the
latest hardware, this design might be a bit of a problem, at least for
my use of using it as a interface between emacs and oprofile.

regards,
	junichi
--

-- 
dancer <at> {debian.org,netfort.gr.jp}   Debian Project

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Maynard Johnson | 6 Mar 18:47 2006
Picon

Re: Proposed XML schema for opreport -X option

Junichi Uekawa wrote:

> Hi,
> 
> 
>>>Our approach is not to extract everything to XML.  Even
>>>with the lean XML format for profile data, there is still
>>>a substantial dilation in the size of the data.   We don't
>>>want to do this to every executable image on thousands of
>>>nodes of a huge cluster.  Hence, we wrote a tool
>>>that extracts detailed profiles only for designated images.
>>
>>My intention with the proposed schema design is that it would be 
>>flexible enough to include as little or as much as what the user asks 
>>for in their profile spec passed into opreport. 
>>
>>Thanks for the constructive comments. 
> 
> 
> I have not yet had the time to fully review your schema, but I have my
> concerns that a full XML output might be too big in size for practical
That's why many of the elements are optional.  So, for example, say you 
  run the profiler without separate=thread, and then you invoke opreport 
with a profile spec to restrict ouptut to only certain binary images. 
Then the resultant XML generated would contain one Module element per 
requested binary image, plus only the SymbolData elements (i.e., 
"samples") corresponding to the specified binary images.

Does this answer your concern, or do you see something in my proposed 
schema that would preclude an optimized output?  I appreciate your time 
in looking at this.

Regards,
-Maynard

> usage. Do you have an example XML output for a system under load, or
> an estimate over size? 
> 
> XML processing isn't free, if it's going to take ~10 seconds on the
> latest hardware, this design might be a bit of a problem, at least for
> my use of using it as a interface between emacs and oprofile.
> 
> regards,
> 	junichi

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Winson Yung | 8 Mar 17:26 2006
Picon

opreport command syntax

Hello again, I want to use opreport to generate symbol summary on multiple .so libraries. Here are two different syntax I tried:

opreport -l libAAA.so, libBBB.so, libCCC.so, libDDD.so, libEEE.so
opreport -l libAAA.so libBBB.so libCCC.so libDDD.so libEEE.so

I do notice that the above two commands will generate different result. By reading the documentation, I was under the impression that I shall probably use comma to list all the .so files.
However with comma delimited syntax, I don' see symbol summary from certain libraries gets included even it is part of the command line. I have about 5-10 libraries to go along with the opreport.

/Winson.

me | 10 Mar 01:20 2006

[PATCH] --session-dir option added

This patch adds a --session-dir=dir option, so the user can specify the session
samples database directory, instead of using the default location
(/var/lib/oprofile).

-Adam Bordelon-
Rice University
Attachment (oprof-session-dir-patch): application/octet-stream, 44 KiB
William Cohen | 13 Mar 20:15 2006
Picon

Re: [Perfctr-devel] 2.6.16-rc5 perfmon2 new code base + libpfm with Montecito support

Stephane Eranian wrote:
> Will,
> 
> On Mon, Mar 13, 2006 at 01:39:01PM -0500, William Cohen wrote:
> 
>>Hi Stephane,
>>
>>I have been looking through the perfmon2 code to see how it is going to 
>>work with OProfile. It looks like the ia64 oprofile support has not been 
>>modified to work with the changes in perfmon2. Has the ia64 kernel been 
>>built with perfmon2 and oprofile support? I don't have easy access to an 
>>ia64, so I haven't been able to verify that the attached patch works. 
>>However, I expect that the changes in the patch will be required for 
>>OProfile to function with perfmon2.
>>
> 
> Good timing. I just fixed this today. Now it compiles fine on
> IA64.  I also started looking into using the same technique on
> i386. It is very easy. It looks like opcontrol or ophelp
> would need to be updated. I think the trick is to make
> sure that ophelp knows the PMU mapping used by perfmon2,
> i.e., knows that PERFEVTSEL0 is PMC0 for instance.
> 

Yes, I have a similar patch for i386 in the kernel. I don't yet have 
modifications for opcontrol or ophelp.

One question would be identifying the processor when using the perfmon2 
support for i386/* processors? There is prior support in the oprofile 
driver for i386 processors. Identify the processor differently depending 
on whether perfmon2 is being used to distinguish between the different 
interfaces? The way that OProfile has the events each name processor 
requires a different directory in /usr/share/oprofile. Would prefer to 
keep down the proliferation of new directories.

-Will

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Stephane Eranian | 13 Mar 21:25 2006
Picon

Re: [Perfctr-devel] 2.6.16-rc5 perfmon2 new code base + libpfm with Montecito support

Will,

On Mon, Mar 13, 2006 at 02:15:53PM -0500, William Cohen wrote:
> 
> Yes, I have a similar patch for i386 in the kernel. I don't yet have 
> modifications for opcontrol or ophelp.

Your patch is very close to mine. I'll merge tthe two and will include
it in my next version.

My understand of opcontrol is that is passes the information from ophelp
to the kernel via /dev/oprofile. I don't know how it passes it to the oprofiled
daemon.

The daemon should not be difficult to change. I hacked something quickly
and got it up on pentium M. The only remaining problem is ophelp, I think.

> One question would be identifying the processor when using the perfmon2 
> support for i386/* processors? There is prior support in the oprofile 
> driver for i386 processors. Identify the processor differently depending 
> on whether perfmon2 is being used to distinguish between the different 
> interfaces? The way that OProfile has the events each name processor 
> requires a different directory in /usr/share/oprofile. Would prefer to 
> keep down the proliferation of new directories.

I think it would be easier to check in /sys/kernel/perfmon to detect
that it is running on perfmon2. Then opcontrol can pass the inormation
around to ophelp, oprofiled is necessary. Ophelp then just needs
to know the perfmon2 register mapping for each CPU. I don't know
how this information is represented today.

--

-- 
-Stephane

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Gmane