Xin Tong | 1 Nov 2011 13:13
Picon

Re: where does oprofile set up the event counters

which part of the src tree builds into the kernel module ?

Thanks

Xin

On Tue, Oct 25, 2011 at 7:17 PM, Maynard Johnson <maynardj <at> us.ibm.com> wrote:
> On 10/23/2011 5:03 AM, Xin Tong wrote:
>>
>> I am looking for the code that actually sets up the event counters in
>> oprofile on x86. I am expecting the code should be soemthing that
>> programming some processor registers. This is currently what I know.
>>
>>  oprof_start::oprof_start
>>      --->  op_get_nr_counters
>>      --->  fill_events
>>  ...
>
> For x86, OProfile userspace simply writes a hex value to
> /dev/oprofile/≤counter_num>/event, and the oprofile kernel driver uses that
> value to do the actual hardware setup.  See
> events/i386/≤processor_type>/events for the hex codes.
>
> -Maynard
>>
>>
>> Kind of lost after this ... Any help will be appreciated.
>>
>> Thanks
>>
(Continue reading)

Robert Richter | 1 Nov 2011 14:50
Picon
Favicon

Re: where does oprofile set up the event counters

On 01.11.11 08:13:08, Xin Tong wrote:
> which part of the src tree builds into the kernel module ?

It is part of the kernel, x86 implementation is here:

 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=arch/x86/oprofile;hb=HEAD

-Robert

--

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

------------------------------------------------------------------------------
RSA&reg; Conference 2012
Save &#36;700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
Robert Richter | 1 Nov 2011 14:56
Picon
Favicon

Re: No samples recorded on VIA C7 (interrupt timer mode)

On 31.10.11 18:52:14, JM wrote:
> I am trying to profile code on the VIA C7 processor [1]. This is a x86
> cpu with no hardware performance counters. I am using oprofile 0.9.7
> and kernel 3.0.4. I am setting oprofile as follows:

Since the rework of the NMI watchdog that bases now on perf, nmi timer
mode is brokten on x86. I posted a reimplementation for 3.3, see:

 http://lkml.org/lkml/2011/10/19/334

This is untested for via cpus, please give it a try.

Alternatively you can try hr timer mode using oprofile.timer=1 kernel
parameter.

Thanks,

-Robert

--

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

------------------------------------------------------------------------------
RSA&reg; Conference 2012
Save &#36;700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
Xin Tong | 1 Nov 2011 15:22
Picon

Re: where does oprofile set up the event counters

and where is the code that actually writes to the device files in oprofile ?

Thanks

Xin

On Tue, Nov 1, 2011 at 9:50 AM, Robert Richter <robert.richter <at> amd.com> wrote:
> On 01.11.11 08:13:08, Xin Tong wrote:
>> which part of the src tree builds into the kernel module ?
>
> It is part of the kernel, x86 implementation is here:
>
>  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=arch/x86/oprofile;hb=HEAD
>
> -Robert
>
> --
> Advanced Micro Devices, Inc.
> Operating System Research Center
>
>

------------------------------------------------------------------------------
RSA&reg; Conference 2012
Save &#36;700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
Robert Richter | 1 Nov 2011 15:55
Picon
Favicon

Re: where does oprofile set up the event counters

On 01.11.11 10:22:19, Xin Tong wrote:
> and where is the code that actually writes to the device files in oprofile ?

Generic code is implemented in drivers/oprofile.

-Robert

--

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

------------------------------------------------------------------------------
RSA&reg; Conference 2012
Save &#36;700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
Robert Richter | 1 Nov 2011 18:54
Picon
Favicon

Re: [V2][PATCH 5/5] oprofile, x86: Reimplement nmi timer mode using perf event

On 23.10.11 07:27:28, Ingo Molnar wrote:
> 
> * Robert Richter <robert.richter <at> amd.com> wrote:
> 
> > The legacy x86 nmi watchdog code was removed with the implementation
> > of the perf based nmi watchdog. This broke Oprofile's nmi timer
> > mode. To run nmi timer mode we relied on a continuous ticking nmi
> > source which the nmi watchdog provided. The nmi tick was no longer
> > available and current watchdog can not be used anymore since it runs
> > with very long periods in the range of seconds. This patch
> > reimplements the nmi timer mode using a perf counter nmi source.
> > 
> > V2:
> > * removing pr_info()
> > * fix undefined reference to `__udivdi3' for 32 bit build
> > * fix section mismatch of .cpuinit.data:nmi_timer_cpu_nb
> > * removed nmi timer setup in arch/x86
> > * implemented function stubs for op_nmi_init/exit()
> > * made code more readable in oprofile_init()
> > 
> > Cc: Peter Zijlstra <a.p.zijlstra <at> chello.nl>
> > Signed-off-by: Robert Richter <robert.richter <at> amd.com>
> > ---
> >  arch/Kconfig                      |    4 +
> >  arch/x86/oprofile/Makefile        |    3 +-
> >  arch/x86/oprofile/init.c          |   30 ++-----
> >  arch/x86/oprofile/nmi_timer_int.c |   66 --------------
> >  drivers/oprofile/nmi_timer_int.c  |  173 +++++++++++++++++++++++++++++++++++++
> >  drivers/oprofile/oprof.c          |   24 +++---
> >  drivers/oprofile/oprof.h          |    9 ++
(Continue reading)

Elan Ruskin | 2 Nov 2011 00:56
Favicon

Can oprofile be made to use a directory other than /root/.oprofile?

We're trying to use oprofileto track down performance problems on a server cluster. However, the servers in question have a read-only file system, where /var/tmp is the only writeable directory.

 

OProfile wants to create two directories whenever it runs: `/root/.oprofile` and `/var/lib/oprofile`, but it can't, because the filesystem is read-only. I can use the `--session-dir` command line option to make it write its logs to elsewhere than `/var/lib`, but I can't find any such option to make it use some other directory than `/root/.oprofile`.

 

The filesystem is read-only because it is on nonwriteable media, not because of permissions -- ie, not even superuser can write to those directories. We can cook a new ROM image of the filesystem (which is how we installed oprofile, obviously), but there is no way for a runtime program to write to /root, whether it is superuser or not.

 

I tried creating a symlink in the ROM that points /root/.oprofile -> /var/tmp/oprofile, but apparently oprofile doesn't see this symlink as a directory, and fails when run:

 

    redacted <at> redacted:~$ sudo opcontrol --no-vmlinux --start --session-dir=/var/tmp/oprofile/foo

    mkdir: cannot create directory `/root/.oprofile': File exists

    Couldn't mkdir -p /root/.oprofile

 

We *must* run our profilers on this particular system, because the performance issues we're trying to investigate don't manifest if we build and run the app on a development server. We can't just run our tests on a programmer's workstation and profile the app there, because the problem doesn't happen there.

 

Is there some way to configure oprofile so that it doesn't use `/root` ?

 

------------------------------------------------------------------------------
RSA&#174; Conference 2012
Save $700 by Nov 18
Register now&#33;
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
oprofile-list mailing list
oprofile-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
Maynard Johnson | 2 Nov 2011 15:59
Picon
Favicon

Re: Can oprofile be made to use a directory other than /root/.oprofile?

Elan Ruskin wrote:
> We're trying to use oprofileto track down performance problems on a server cluster. However, the servers
in question have a read-only file system, where /var/tmp is the only writeable directory.
> 
> OProfile wants to create two directories whenever it runs: `/root/.oprofile` and
`/var/lib/oprofile`, but it can't, because the filesystem is read-only. I can use the `--session-dir`
command line option to make it write its logs to elsewhere than `/var/lib`, but I can't find any such option
to make it use some other directory than `/root/.oprofile`.
> 
> The filesystem is read-only because it is on nonwriteable media, not because of permissions -- ie, not
even superuser can write to those directories. We can cook a new ROM image of the filesystem (which is how we
installed oprofile, obviously), but there is no way for a runtime program to write to /root, whether it is
superuser or not.
> 
> I tried creating a symlink in the ROM that points /root/.oprofile -> /var/tmp/oprofile, but apparently
oprofile doesn't see this symlink as a directory, and fails when run:
> 
>     redacted <at> redacted:~$ sudo opcontrol --no-vmlinux --start --session-dir=/var/tmp/oprofile/foo
>     mkdir: cannot create directory `/root/.oprofile': File exists
>     Couldn't mkdir -p /root/.oprofile
> 
> We *must* run our profilers on this particular system, because the performance issues we're trying to
investigate don't manifest if we build and run the app on a development server. We can't just run our tests
on a programmer's workstation and profile the app there, because the problem doesn't happen there.
> 
> Is there some way to configure oprofile so that it doesn't use `/root` ?
I'm afraid there's no configure option or runtime option, but the behavior can be easily changed by
modifying the opcontrol script (found in the utils dir of the oprofile source tree).  Simply change the
line that reads:
       SETUP_DIR="/root/.oprofile"
to
       SETUP_DIR="/var/tmp/.oprofile" #or whatever path you want

-Maynard

> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> RSA&#174; Conference 2012
> Save $700 by Nov 18
> Register now&#33;
> http://p.sf.net/sfu/rsa-sfdev2dev1
> 
> 
> 
> _______________________________________________
> oprofile-list mailing list
> oprofile-list <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oprofile-list

------------------------------------------------------------------------------
RSA&#174; Conference 2012
Save $700 by Nov 18
Register now&#33;
http://p.sf.net/sfu/rsa-sfdev2dev1
Andreas Krebbel | 2 Nov 2011 16:10
Picon

[PATCH 1/2]: S/390: Add event interface to the System z hardware sampling kernel part

With this patch the OProfile Basic Mode Sampling support for System z
is enhanced with a counter file system.  That way hardware sampling
can be enabled/disabled using different events (TIMER and HWSAMPLING).

This patch breaks existing OProfile user space tools.  The cpu_type
will now indicate that the hardware sampling facility is available.
Existing user space tools will complain about an unknown cpu type.  If
you encounter this problem please update your OProfile user space
tools.

In the counter file system only the values of 'event', 'kernel', and
'user' are evaluated by the kernel module. Everything else is either
ignored or must contain fixed values.

The 'kernel' and 'user' flags can now be used to filter for samples.

Signed-off-by: Andreas Krebbel <krebbel <at> linux.vnet.ibm.com>
---
 arch/s390/oprofile/hwsampler.c  |    7 ++++++-
 arch/s390/oprofile/init.c       |   37 +++++++++++++++++++++++++++++++++++--
 arch/s390/oprofile/op_counter.h |   25 +++++++++++++++++++++++++
 3 files changed, 66 insertions(+), 3 deletions(-)

--- a/arch/s390/oprofile/hwsampler.c
+++ b/arch/s390/oprofile/hwsampler.c
 <at>  <at>  -22,6 +22,7  <at>  <at> 
 #include <asm/irq.h>

 #include "hwsampler.h"
+#include "op_counter.h"

 #define MAX_NUM_SDB 511
 #define MIN_NUM_SDB 1
 <at>  <at>  -896,6 +897,8  <at>  <at>  static void add_samples_to_oprofile(unsi
 		if (sample_data_ptr->P == 1) {
 			/* userspace sample */
 			unsigned int pid = sample_data_ptr->prim_asn;
+			if (!counter_config.user)
+				goto skip_sample;
 			rcu_read_lock();
 			tsk = pid_task(find_vpid(pid), PIDTYPE_PID);
 			if (tsk)
 <at>  <at>  -903,6 +906,8  <at>  <at>  static void add_samples_to_oprofile(unsi
 			rcu_read_unlock();
 		} else {
 			/* kernelspace sample */
+			if (!counter_config.kernel)
+				goto skip_sample;
 			regs = task_pt_regs(current);
 		}

 <at>  <at>  -910,7 +915,7  <at>  <at>  static void add_samples_to_oprofile(unsi
 		oprofile_add_ext_hw_sample(sample_data_ptr->ia, regs, 0,
 				!sample_data_ptr->P, tsk);
 		mutex_unlock(&hws_sem);
-
+	skip_sample:
 		sample_data_ptr++;
 	}
 }
--- a/arch/s390/oprofile/init.c
+++ b/arch/s390/oprofile/init.c
 <at>  <at>  -22,6 +22,7  <at>  <at>  extern void s390_backtrace(struct pt_reg
 #ifdef CONFIG_64BIT

 #include "hwsampler.h"
+#include "op_counter.h"

 #define DEFAULT_INTERVAL	4127518

 <at>  <at>  -40,6 +41,8  <at>  <at>  static int hwsampler_running;	/* start_m

 static struct oprofile_operations timer_ops;

+struct op_counter_config counter_config;
+
 static int oprofile_hwsampler_start(void)
 {
 	int retval;
 <at>  <at>  -112,10 +115,15  <at>  <at>  static const struct file_operations hwsa
 static int oprofile_create_hwsampling_files(struct super_block *sb,
 						struct dentry *root)
 {
-	struct dentry *hw_dir;
+	struct dentry *hw_dir, *dir;

 	/* reinitialize default values */
 	hwsampler_file = 1;
+	counter_config.count = 0;
+	counter_config.enabled = 1;
+	counter_config.unit_mask = 0;
+	counter_config.kernel = 1;
+	counter_config.user = 1;

 	hw_dir = oprofilefs_mkdir(sb, root, "hwsampling");
 	if (!hw_dir)
 <at>  <at>  -131,6 +139,30  <at>  <at>  static int oprofile_create_hwsampling_fi
 	oprofilefs_create_ulong(sb, hw_dir, "hw_sdbt_blocks",
 				&oprofile_sdbt_blocks);

+	/* Create the counter file system.  A single virtual counter
+	 * is created which can be used to enable/disable hardware
+	 * sampling dynamically from user space.  The user space will
+	 * configure a single counter with two events 0 and 1.  Using
+	 * event 0 enables use of timer based sampling while event 1
+	 * turns on hardware sampling.  These values have to stay like
+	 * this since the /dev/oprofile/0/event always has to match
+	 * /dev/oprofile/hwsampling/hwsampler content in order to
+	 * support the existing interface in parallel.  Apart from
+	 * 'event' only the 'kernel' and 'user' flags are evaluated by
+	 * the kernel code.  */
+
+	dir = oprofilefs_mkdir(sb, root, "0");
+	if (!dir)
+		return -EINVAL;
+
+	oprofilefs_create_ulong(sb, dir, "enabled", &counter_config.enabled);
+	oprofilefs_create_file(sb, dir, "event", &hwsampler_fops);
+	oprofilefs_create_ulong(sb, dir, "count", &counter_config.count);
+	oprofilefs_create_ulong(sb, dir, "unit_mask", &counter_config.unit_mask);
+	oprofilefs_create_ulong(sb, dir, "kernel", &counter_config.kernel);
+	oprofilefs_create_ulong(sb, dir, "user", &counter_config.user);
+	oprofilefs_create_ulong(sb, dir, "extra", &counter_config.extra);
+
 	return 0;
 }

 <at>  <at>  -158,13 +190,14  <at>  <at>  static int oprofile_hwsampler_init(struc
 	if (oprofile_timer_init(ops))
 		return -ENODEV;

-	printk(KERN_INFO "oprofile: using hardware sampling\n");
+	printk(KERN_INFO "OProfile: System z hardware sampling facility found.\n");

 	memcpy(&timer_ops, ops, sizeof(timer_ops));

 	ops->start = oprofile_hwsampler_start;
 	ops->stop = oprofile_hwsampler_stop;
 	ops->create_files = oprofile_create_hwsampling_files;
+	ops->cpu_type = "s390x/basic_mode_sampling_v1";

 	return 0;
 }
--- /dev/null
+++ b/arch/s390/oprofile/op_counter.h
 <at>  <at>  -0,0 +1,25  <at>  <at> 
+/**
+ * arch/s390/oprofile/op_counter.h
+ *
+ *   Copyright (C) 2011 IBM Deutschland Entwicklung GmbH, IBM Corporation
+ *   Author(s): Andreas Krebbel (krebbel <at> linux.vnet.ibm.com)
+ *
+ *  <at> remark Copyright 2011 OProfile authors
+ */
+
+#ifndef OP_COUNTER_H
+#define OP_COUNTER_H
+
+struct op_counter_config {
+	/* `event' maps to the hwsampler_file variable */
+	unsigned long count;     /* unused */
+	unsigned long enabled;   /* unused */
+	unsigned long kernel;
+	unsigned long user;
+	unsigned long unit_mask; /* always zero */
+	unsigned long extra;     /* unused */
+};
+
+extern struct op_counter_config counter_config;
+
+#endif /* OP_COUNTER_H */

------------------------------------------------------------------------------
RSA&#174; Conference 2012
Save $700 by Nov 18
Register now&#33;
http://p.sf.net/sfu/rsa-sfdev2dev1
Andreas Krebbel | 2 Nov 2011 16:10
Picon

[PATCH 2/2] S/390: Enhance the user space tools for System z hardware sampling

This patch makes use of the event mechanism to allow for dynamic
enabling and disabling of the System z hardware sampling facility with
the OProfile user space tools.

A single virtual counter is created which can be used to
enable/disable hardware sampling dynamically from user space.  The
counter can be used with the two events 0 and 1.  Using event 0
enables use of timer based sampling while event 1 turns on hardware
sampling.  These values have to stay like this since the
/dev/oprofile/0/event always has to match
/dev/oprofile/hwsampling/hwsampler content in order to support the
existing interface in parallel.  Apart from 'event' only the 'kernel'
and 'user' flags are evaluated by the kernel code.

This adds two new opcontrol options --s390hwsampbufsize and
--s390hwsamprate which can be used to set the two hardware sampling
specific values at opcontrol cmdline.

Signed-off-by: Andreas Krebbel <krebbel <at> linux.vnet.ibm.com>
---
 doc/oprofile.xml                               |   62 ++++++++++++++++++
 events/Makefile.am                             |    4 -
 events/s390x/basic_mode_sampling_v1/events     |    8 ++
 events/s390x/basic_mode_sampling_v1/unit_masks |    8 ++
 libop/op_cpu_type.c                            |    1 
 libop/op_cpu_type.h                            |    1 
 libop/op_events.c                              |    3 
 libpp/op_header.cpp                            |   10 +-
 utils/opcontrol                                |   84 +++++++++++++++++++++++++
 utils/ophelp.c                                 |    4 +
 10 files changed, 179 insertions(+), 6 deletions(-)

--- a/doc/oprofile.xml
+++ b/doc/oprofile.xml
 <at>  <at>  -1328,6 +1328,68  <at>  <at>  Note: * All IBS fetch event must have th

 </sect2>

+<sect2 id="systemz">
+<title>IBM System z hardware sampling support</title>
+<para>
+IBM System z provides a facility which does instruction sampling as
+part of the CPU.  This has great advantages over the timer based
+sampling approach like better sampling resolution with less overhead
+and the possibility to get samples within code sections where
+interrupts are disabled (useful especially for Linux kernel code).
+</para>
+<para>
+A public description of the System z CPU-Measurement Facilities can be
+found here:
+<ulink
url="http://www-01.ibm.com/support/docview.wss?uid=isg26fcd1cc32246f4c8852574ce0044734a">The
Load-Program-Parameter and CPU-Measurement Facilities</ulink>
+</para>
+<para>
+System z hardware sampling can be used for Linux instances in LPAR
+mode. The hardware sampling support used by OProfile was introduced
+for System z10 in October 2008.
+</para>
+<para>
+To enable hardware sampling for an LPAR you must activate the LPAR
+with authorization for basic sampling control. See the "Support
+Element Operations Guide" for your mainframe system for more
+information.
+</para>
+<para>
+The hardware sampling facility can be enabled and disabled using the
+event interface.  A `virtual' counter 0 has been defined that supports
+two events, TIMER and HWSAMPLING. By default the HWSAMPLING event is
+used on machines providing the facility.  For both events only the
+`kernel' and `user' flags are evaluated by the kernel module.
+</para>
+<para>
+Altough <command>opcontrol</command> requires to specify a value for
+`count' this value is ignored.
+</para>
+<para>
+The unit mask `um' is required to be zero.
+</para>
+<para>
+Since the counter is needed for both available sampling modes it is
+always enabled and cannot be disabled by writing into
+the <filename>events/0/enabled</filename> file.
+</para>
+<para>
+The opcontrol tool provides a few options specific to System z
+hardware sampling. The hardware sampling rate and the sampling buffer
+size is stored into the OProfile configuration file.
+</para>
+
+<itemizedlist>
+<listitem>--s390hwsamprate="cycles"
+Number of machine cycles between taking samples.</listitem>
+<listitem>--s390hwsampbufsize="buffers"
+Number of 2MB areas used per CPU for storing sample data.  The best
+size for the sample memory depends on the particular system and the
+workload to be measured.  Providing the sampler with too little memory
+results in lost samples. Reserving too much system memory for the
+sampler impacts the overall performance and, hence, also the workload
+to be measures</listitem>
+</itemizedlist>
+</sect2>

 <sect2 id="misuse">
 <title>Dangerous counter settings</title>
--- a/events/Makefile.am
+++ b/events/Makefile.am
 <at>  <at>  -68,8 +68,8  <at>  <at>  event_files = \
 	ppc/7450/events ppc/7450/unit_masks \
 	ppc/e500/events ppc/e500/unit_masks \
 	ppc/e500v2/events ppc/e500v2/unit_masks \
-	ppc/e300/events ppc/e300/unit_masks
-
+	ppc/e300/events ppc/e300/unit_masks \
+	s390x/basic_mode_sampling_v1/events s390x/basic_mode_sampling_v1/unit_masks
 install-data-local:
 	for i in ${event_files} ; do \
 		dir=`dirname $$i` ; \
--- /dev/null
+++ b/events/s390x/basic_mode_sampling_v1/events
 <at>  <at>  -0,0 +1,8  <at>  <at> 
+# Copyright OProfile authors
+# Copyright (c) International Business Machines, 2011.
+# Contributed by Andreas Krebbel <krebbel <at> linux.vnet.ibm.com>.
+#
+# S/390 Basic Mode Sampling events
+#
+event:0x00 counters:0 um:zero minimum:100 name:TIMER : Sampling using timer interrupt
+event:0x01 counters:0 um:zero minimum:0 name:HWSAMPLING : Sampling using Basic Mode Hardware Sampling
--- /dev/null
+++ b/events/s390x/basic_mode_sampling_v1/unit_masks
 <at>  <at>  -0,0 +1,8  <at>  <at> 
+# Copyright OProfile authors#
+# Copyright (c) International Business Machines, 2011.
+# Contributed by Andreas Krebbel <krebbel <at> linux.vnet.ibm.com>.
+#
+# S/390 Basic Mode Hardware Sampling unit masks
+#
+name:zero type:mandatory default:0x0
+	0x0 No unit mask
--- a/libop/op_cpu_type.c
+++ b/libop/op_cpu_type.c
 <at>  <at>  -94,6 +94,7  <at>  <at>  static struct cpu_descr const cpu_descrs
 	{ "ARMv7 Scorpion", "arm/armv7-scorpion", CPU_ARM_SCORPION, 5 },
 	{ "ARMv7 ScorpionMP", "arm/armv7-scorpionmp", CPU_ARM_SCORPIONMP, 5 },
 	{ "Intel Sandy Bridge microarchitecture", "i386/sandybridge", CPU_SANDYBRIDGE, 8 },
+	{ "IBM System z with basic mode hardware sampling support", "s390x/basic_mode_sampling_v1",
CPU_S390_HWSAMPV1, 1 },
 };

 static size_t const nr_cpu_descrs = sizeof(cpu_descrs) / sizeof(struct cpu_descr);
--- a/libop/op_cpu_type.h
+++ b/libop/op_cpu_type.h
 <at>  <at>  -91,6 +91,7  <at>  <at>  typedef enum {
 	CPU_ARM_SCORPION, /**≤ ARM SCORPION */
 	CPU_ARM_SCORPIONMP, /**≤ ARM SCORPIONMP */
 	CPU_SANDYBRIDGE, /* Intel Sandy-Bridge microarchitecture */
+	CPU_S390_HWSAMPV1, /* IBM System z with Basic Mode Sampling support */
 	MAX_CPU_TYPE
 } op_cpu;

--- a/libop/op_events.c
+++ b/libop/op_events.c
 <at>  <at>  -1125,6 +1125,9  <at>  <at>  void op_default_event(op_cpu cpu_type, s
 		case CPU_PPC_E300:
 			descr->name = "CPU_CLK";
 			break;
+	        case CPU_S390_HWSAMPV1:
+			descr->name = "HWSAMPLING";
+			break;

 		// don't use default, if someone add a cpu he wants a compiler
 		// warning if he forgets to handle it here.
--- a/libpp/op_header.cpp
+++ b/libpp/op_header.cpp
 <at>  <at>  -254,11 +254,13  <at>  <at>  string const describe_cpu(opd_header con
 		str = xml_utils::get_profile_header(cpu_name, header.cpu_speed);
 	} else {
 		str += string("CPU: ") + op_get_cpu_type_str(cpu);
-		str += ", speed ";
+		if (header.cpu_speed > 0) {
+			ostringstream ss;

-		ostringstream ss;
-		ss << header.cpu_speed;
-		str += ss.str() + " MHz (estimated)";
+			str += ", speed ";
+			ss << header.cpu_speed;
+			str += ss.str() + " MHz (estimated)";
+		}
 	}
 	return str;
 }
--- a/utils/opcontrol
+++ b/utils/opcontrol
 <at>  <at>  -239,6 +239,11  <at>  <at>  opcontrol: usage:
    --xen                         Xen image (for Xen only)
    --active-domains=<list>       List of domains in profiling session (for Xen)
                                  (list contains domain ids separated by commas)
+
+  System z specific options
+
+  --s390hwsamprate=cycles	 Number of machine cycles between taking samples.
+  --s390hwsampbufsize=buffers	 Number of 2MB areas used per CPU for storing sample data.
 EOF
 }

 <at>  <at>  -381,6 +386,11  <at>  <at>  do_init()
 	IBS_OP_COUNT=0
 	IBS_OP_UNITMASK=0

+	# System z specific values
+	S390_HW_SAMPLER=0
+	S390_HW_SAMPLER_RATE=0
+	S390_HW_SAMPLER_BUFSIZE=0
+
 	OPROFILED="$OPDIR/oprofiled"

 	# location for daemon setup information
 <at>  <at>  -405,6 +415,9  <at>  <at>  do_init()
 		IS_TIMER=1
 	else
 		case "$CPUTYPE" in
+			s390x/basic_mode_sampling_v1)
+				S390_HW_SAMPLER=1
+				;;
 			ia64/*)
 				IS_PERFMON=$KERNEL_SUPPORT
 				;;
 <at>  <at>  -496,6 +509,14  <at>  <at>  do_save_setup()
 	if test "$XEN_RANGE"; then
 		echo "XEN_RANGE=$XEN_RANGE" >> $SETUP_FILE
 	fi
+	if test "$S390_HW_SAMPLER" == "1"; then
+		if test "$S390_HWSAMPLER_RATE" != "0"; then
+			echo "S390_HW_SAMPLER_RATE=$S390_HW_SAMPLER_RATE" >> $SETUP_FILE
+		fi
+		if test "$S390_HWSAMPLER_BUFSIZE" != "0"; then
+			echo "S390_HW_SAMPLER_BUFSIZE=$S390_HW_SAMPLER_BUFSIZE" >> $SETUP_FILE
+		fi
+	fi
 	SETUP_FILE="$SAVE_SETUP_FILE"
 }

 <at>  <at>  -538,6 +559,32  <at>  <at>  do_load_setup()
 	done < $SETUP_FILE
 }

+# Various checks related to Hardware sampler option
+check_platform_args()
+{
+	case "$CPUTYPE" in
+		s390x/basic_mode_sampling_v1)
+			if test "$S390_HW_SAMPLER_RATE" == "0"; then
+				return
+			fi
+			if test -r $MOUNT/hwsampling/hw_min_interval; then
+				min_interval=`cat $MOUNT/hwsampling/hw_min_interval`
+			fi
+			if test -r $MOUNT/hwsampling/hw_max_interval; then
+				max_interval=`cat $MOUNT/hwsampling/hw_max_interval`
+ 			fi
+
+			if test "$S390_HW_SAMPLER_RATE" -lt "$min_interval" -o \
+				"$S390_HW_SAMPLER_RATE" -gt "$max_interval"; then
+				echo "Invalid value for hardware sampling rate" >&2
+				echo "should be between $min_interval and $max_interval" >&2
+				exit 1
+			fi
+			;;
+		*)
+			;;
+	esac
+}

 check_valid_args()
 {
 <at>  <at>  -971,6 +1018,19  <at>  <at>  do_options()
 				exec $OPHELP
 				;;

+			--s390hwsamprate)
+				error_if_not_number "$arg" "$val"
+				S390_HW_SAMPLER_RATE=$val
+				DO_SETUP=yes
+				;;
+
+			--s390hwsampbufsize)
+				error_if_not_number "$arg" "$val"
+				S390_HW_SAMPLER_BUFSIZE=$val
+				DO_SETUP=yes
+				;;
+
+
 			*)
 				echo "Unknown option \"$arg\". See opcontrol --help" >&2
 				exit 1
 <at>  <at>  -1418,6 +1478,15  <at>  <at>  do_param_setup()
 		return
 	fi

+	if test "$S390_HW_SAMPLER" == "1"; then
+		if test "$S390_HW_SAMPLER_RATE" != "0"; then
+			echo $S390_HW_SAMPLER_RATE >$MOUNT/hwsampling/hw_interval
+		fi
+		if test "$S390_HW_SAMPLER_BUFSIZE" != "0"; then
+			echo $S390_HW_SAMPLER_BUFSIZE >$MOUNT/hwsampling/hw_sdbt_blocks
+		fi
+	fi
+
 	# use the default setup if none set
 	if test "$NR_CHOSEN" = 0; then
 		set_event 0 $DEFAULT_EVENT
 <at>  <at>  -1701,6 +1770,20  <at>  <at>  do_status()
 			echo "CPU buffer size: $CPU_BUF_SIZE"
 		fi
 	fi
+	if test "$S390_HW_SAMPLER" == "1"; then
+		echo -n "System z hardware sampling rate in cycles: "
+		if test "$S390_HW_SAMPLER_RATE" == "0"; then
+			cat $MOUNT/hwsampling/hw_interval
+		else
+			echo "$S390_HW_SAMPLER_RATE"
+		fi
+		echo -n "System z hardware sampling buffer size (in 2MB areas): "
+		if test "$S390_HW_SAMPLER_BUFSIZE" == "0"; then
+			cat $MOUNT/hwsampling/hw_sdbt_blocks
+		else
+			echo "$S390_HW_SAMPLER_BUFSIZE"
+		fi
+	fi

 	exit 0
 }
 <at>  <at>  -1855,6 +1938,7  <at>  <at>  do_operations()
 	fi

 	if test "$SETUP" = "yes"; then
+		check_platform_args
 		check_valid_args
 		do_save_setup
 	fi
--- a/utils/ophelp.c
+++ b/utils/ophelp.c
 <at>  <at>  -731,6 +731,10  <at>  <at>  int main(int argc, char const * argv[])
 			"Chapter 6: Performance Counters\n"
 			"http://www.atmel.com/dyn/resources/prod_documents/doc32000.pdf\n";

+	case CPU_S390_HWSAMPV1:
+		event_doc = "IBM System z Basic Mode Sampling\n";
+		break;
+
 		case CPU_RTC:
 			break;

------------------------------------------------------------------------------
RSA&#174; Conference 2012
Save $700 by Nov 18
Register now&#33;
http://p.sf.net/sfu/rsa-sfdev2dev1

Gmane