[patch 2/4] This patch enhances OProfile to support System zs hardware sampling feature

Previous thread: [patch 4/4] Handle memory unmap while hardware sampling is running by graalfs on Monday, December 20, 2010 - 6:05 am. (2 messages)

Next thread: [patch 3/4] This patch introduces a new oprofile sample add function (oprofile_add_ext_hw_sample) by graalfs on Monday, December 20, 2010 - 6:05 am. (2 messages)
From: graalfs
Date: Monday, December 20, 2010 - 6:05 am

From: graalfs@linux.vnet.ibm.com

OProfile is enhanced to export all files for controlling System z's hardware sampling,
and to invoke hwsampler exported functions to initialize and use System z's hardware sampling.

The patch invokes hwsampler_setup() during oprofile init and exports following
hwsampler files under oprofilefs if hwsampler's setup succeeded:

A new directory for hardware sampling based files

 /dev/oprofile/hwsampling/

The userland daemon must explicitly write to the following files
to disable (or enable) hardware based sampling

 /dev/oprofile/hwsampling/hwsampler

to modify the actual sampling rate

 /dev/oprofile/hwsampling/hw_interval

to modify the amount of sampling memory (measured in 4K pages)

 /dev/oprofile/hwsampling/hw_sdbt_blocks

The following files are read only and show
the possible minimum sampling rate

 /dev/oprofile/hwsampling/hw_min_interval

the possible maximum sampling rate

 /dev/oprofile/hwsampling/hw_max_interval

The patch splits the oprofile_timer_[init/exit] function so that it can be also called
through user context (oprofilefs) to avoid kernel oops.

Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Maran Pakkirisamy <maranp@linux.vnet.ibm.com>
Signed-off-by: Heinz Graalfs <graalfs@linux.vnet.ibm.com>
---
 arch/s390/oprofile/Makefile          |    1 
 arch/s390/oprofile/hwsampler_files.c |  120 +++++++++++++++++++++++++++++++++++
 arch/s390/oprofile/init.c            |   35 ++++++++++
 drivers/oprofile/oprof.c             |   37 ++++++++++
 drivers/oprofile/oprof.h             |    2 
 drivers/oprofile/timer_int.c         |   16 +++-
 include/linux/oprofile.h             |   15 ++++
 7 files changed, 223 insertions(+), 3 deletions(-)

Index: linux-2.6/arch/s390/oprofile/Makefile
===================================================================
--- linux-2.6.orig/arch/s390/oprofile/Makefile
+++ linux-2.6/arch/s390/oprofile/Makefile
@@ -8,6 +8,7 @@ DRIVER_OBJS = $(addprefix ...
From: Robert Richter
Date: Monday, January 3, 2011 - 12:02 pm

I would rather see a file hwsampler.c here that contains all oprofile
hwsampler code in it and also sets up a struct oprofile_operations*
ops.

Doing so, most of global functions and variables below can be made

We should find a better solution than changing all those files only





Wouldn't it be better to have a different cpu_type string here, I
don't think the oprofilefs interface is exactly the same as for timer


Is there a use case for switching the mode at runtime? There are
kernel parameters to force timer mode while booting or loading the
module. I don't like exporting all these timer and hwsampler
functions. We could avoid this by making hwsampler architectural code




This is not generic code, there is no other architecture that may

This becomes static if we move it to arch/s390/oprofile/hwsampler.c

Move all the code for CONFIG_OPROFILE_HWSAMPLING_MODE in this file to 

 arch/s390/oprofile/hwsampler.c

and only export an oprofile_hwsampler_init() function. This can be an

Same here...


-- 
Advanced Micro Devices, Inc.
Operating System Research Center

--

Previous thread: [patch 4/4] Handle memory unmap while hardware sampling is running by graalfs on Monday, December 20, 2010 - 6:05 am. (2 messages)

Next thread: [patch 3/4] This patch introduces a new oprofile sample add function (oprofile_add_ext_hw_sample) by graalfs on Monday, December 20, 2010 - 6:05 am. (2 messages)