OProfile now in Debian unstable

Just thought the Debian users on the list
would be interested in this: OProfile was
accepted into unstable (i386 and ia64) as
of 26 Dec 2003.  It should show up in your
nearby Debian mirror in the next few days.

Note that the version uploaded is 0.6.1
(so a little stale) but 0.7 should be
ready in the next week or two.  Also, the
Debian kernel maintainer has agreed to
including the oprofile kernel module as
part of the standard Debian kernel images.

Pretty cool, eh :)?  Kind of a nice little
Christmas gift, I thought....

--

-- 
Ciao,
al
----------------------------
Al Stone
Linux & Open Source Lab
Hewlett-Packard Company
Phone:  970-898-0345
Telnet:     898-0345
Fax:    970-898-3804
E-mail: ahs3 <at> fc.hp.com
----------------------------

-------------------------------------------------------

OProfile Support for Java JIT code

Here is a strawman proposal descrbing how we might implement support for 
Java with JIT translation. There are still a number of places where 
things need to be fleshed out more, e.g. the generation of 
executable-like file by the Java profiling agent. There are also many 
places where I have "FIXME:". I would appreciate comments and 
suggestions on it.

-Will

Strawman Proposal: OProfile Support for Java Runtime Environments

Will Cohen

Many programmers are interested in using OProfile to get profiling
information for Java programs running on commercial JREs which use
Just-In-Time translation.  This proposal outlines enhancements to
OProfile to enable collection of profiling data for Java programs
running on Java Runtime Environments (JREs) that have Just-In-Time
(JIT) translated code, e.g. Sun's and IBM's java systems.

Currently, OProfile only collects samples for regions of code that map
to files. This presents a problem for JREs that perform JIT
translation, where the executable code is not directly mapped to a
region of a file. OProfile discards the samples for regions of code
that are not mmapped from a file. The interface between the kernel and
the daemon also expects that each sample is associated with a file
that can be looked up via a dcookie number. Kernel-space samples are
an exception to this.

kernel 2.6.0 nmi_timer_int.c patch

I happen to be compiling the 2.6.0 kernel with CONFIG_X86_IO_APIC set 
and found that a correction was needed for 
linux/arch/i386/oprofile/nmi_timer_int.c.

-Will

--- linux-2.6.0/arch/i386/oprofile/nmi_timer_int.c	2003-12-17 21:58:38.000000000 -0500
+++ linux-2.6.0-1.30-callback/arch/i386/oprofile/nmi_timer_int.c	2004-01-09
17:45:40.000000000 -0500
 <at>  <at>  -20,9 +20,7  <at>  <at> 

 static int nmi_timer_callback(struct pt_regs * regs, int cpu)
 {
-	unsigned long eip = instruction_pointer(regs);
- 
-	oprofile_add_sample(eip, !user_mode(regs), 0, cpu);
+	oprofile_add_sample(regs, 0);
 	return 1;
 }

Re: kernel 2.6.0 nmi_timer_int.c patch

On Fri, Jan 09, 2004 at 06:04:02PM -0500, William Cohen wrote:

> I happen to be compiling the 2.6.0 kernel with CONFIG_X86_IO_APIC set 
> and found that a correction was needed for 
> linux/arch/i386/oprofile/nmi_timer_int.c.

You seem to have a patch applied ? The prototype only changes like this
in the callgraph patch ...

regards
john
--

-- 
Khendon's Law:
If the same point is made twice by the same person, the thread is over.

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Adding sys_call_table to RH distributions

Re: Adding sys_call_table to RH distributions

On Fri, Jan 09, 2004 at 04:21:45PM -0800, Foong, Annie wrote:

> also, does RH 9 have its own distribution of oprofile?

Yes, just install it off the CD if you haven't already.

john

--

-- 
Khendon's Law:
If the same point is made twice by the same person, the thread is over.

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: kernel 2.6.0 nmi_timer_int.c patch

John Levon wrote:
> On Fri, Jan 09, 2004 at 06:04:02PM -0500, William Cohen wrote:
> 
> 
>>I happen to be compiling the 2.6.0 kernel with CONFIG_X86_IO_APIC set 
>>and found that a correction was needed for 
>>linux/arch/i386/oprofile/nmi_timer_int.c.
> 
> 
> You seem to have a patch applied ? The prototype only changes like this
> in the callgraph patch ...

yes, this was the callgraph patch. -Will
> 
> regards
> john

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: kernel 2.6.0 nmi_timer_int.c patch

William Cohen wrote:
> I happen to be compiling the 2.6.0 kernel with CONFIG_X86_IO_APIC set 
> and found that a correction was needed for 
> linux/arch/i386/oprofile/nmi_timer_int.c.
> 
> -Will
> 
> 
> ------------------------------------------------------------------------
> 
> --- linux-2.6.0/arch/i386/oprofile/nmi_timer_int.c	2003-12-17 21:58:38.000000000 -0500
> +++ linux-2.6.0-1.30-callback/arch/i386/oprofile/nmi_timer_int.c	2004-01-09
17:45:40.000000000 -0500
>  <at>  <at>  -20,9 +20,7  <at>  <at> 
>   
>  static int nmi_timer_callback(struct pt_regs * regs, int cpu)
>  {
> -	unsigned long eip = instruction_pointer(regs);
> - 
> -	oprofile_add_sample(eip, !user_mode(regs), 0, cpu);
> +	oprofile_add_sample(regs, 0);
>  	return 1;
>  }
>  

last callgraph patch is here and contain this chunck

http://perso.wanadoo.fr/phil.el/

regards,
Phil

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: OProfile Support for Java JIT code

Will Cohen wrote:
> Here is a strawman proposal descrbing how we might implement support for 
> Java with JIT translation. There are still a number of places where 
> things need to be fleshed out more, e.g. the generation of 
> executable-like file by the Java profiling agent. There are also many 
> places where I have "FIXME:". I would appreciate comments and 
> suggestions on it.

Look like a good start.

[...]

> (FIXME: how to deal with high-to-low allocation of JITed code segments
> efficiently? Just leave the sample address as VMA and have a post
> processing pass that read in the JITed files and samples and sorts the
> JITed methods, combines them into a single block, converts the VMAs
> into offset, new files written, so this doesn't screw up the daemon or
> currently running java code.)

Does the JVM use a fixed amount of memory and drop some segments
if there is not enough free room in the translation buffer ?
Does this occurs never/rarely/commonly ?

Is it required by the JVM definition than all process
get a different address space ?

regards,
Phil

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

callgraph collection

I have started to look over the OProfile patch for the call graphs at 
http://perso.wanadoo.fr/phil.el/.

The traceback collection is either on for all events or off for all 
events. It seems like it would be useful to limit the traceback 
collection to a subset of events being measured. Something that would be 
ideal would be just take the stack back trace on function call events to 
get the context information and then have other events such as cache 
misses just take eip samples and not bother with the stack. Having this 
subseting might also reduce the problem of running out of CPU buffer 
space mentioned in oprofile-callgraph/TODO. Maybe have a 
/dev/oprofile/[0-9]+/backtrace_depth to set it for individual events; 0 
no backtrace and max 32.

Limiting call analysis to only calls that do not cross between 
executable seems pretty severe: From the webpage:

  Only opgprof can handle call graph, so only gprof style output. 
Currently we can't handle call graph between different binary (you can 
output callgraph for a shared libs but you can't see call graph of 
caller/callee outside this shared library)

It would be really useful to know which libraries are being used in the 
case of "--separate=library". What is the reason for the restriction? If 
this limitation can be eliminated, that would be a big help for 
application programmers few people statically link things into one big 
executable.

-Will

-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html