Граф коммитов

6 Коммитов

Автор SHA1 Сообщение Дата
Heiko Carstens 984e8486c1 [S390] oprofile: disable hw sampling for CONFIG_32BIT
Doesn't work and build for CONFIG_32BIT. So disable it.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2011-03-23 10:15:14 +01:00
Heinz Graalfs c814d160f6 oprofile, s390: Remove hwsampler_files.c and merge it into init.c
Merge the contents of hwsampler_files.c into
arch/s390/oprofile/init.c.

Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Heinz Graalfs <graalfs@linux.vnet.ibm.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
2011-03-16 14:05:35 +01:00
Heinz Graalfs 997dbb4967 oprofile, s390: Enhance OProfile to support System zs hardware sampling feature
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.

Applied with following changes:
* whitespace changes in Makefile and timer_int.c

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>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
2011-02-15 11:08:50 +01:00
Heinz Graalfs ec6a3df1c0 oprofile, s390: Add support for hardware based sampling on System z processors
This adds support for hardware based sampling on System z processors
(models z10 and up).

System z's hardware sampling is described in detail in:

   SA23-2260-01 "The Load-Program-Parameter and CPU-Measurement Facilities"

The patch introduces

 - support for System z's hardware sampler in OProfile's kernel module
 - it adds functions that control all hardware sampling related
   operations as:
   - checking if hardware sampling feature is available, i.e.: on
     System z models z10 and up, in LPAR mode only, and authorised
     during LPAR activation
   - allocating memory for the hardware sampling feature
   - starting/stopping hardware sampling

All functions required to start and stop hardware sampling have to be
invoked by the oprofile kernel module as provided by the other patches
of this patch set.

In case hardware based sampling cannot be setup standard timer based
sampling is used by OProfile.

Applied with following changes:
* enable compilation in Makefile

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>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Robert Richter <robert.richter@amd.com>
2011-02-15 11:08:19 +01:00
Andreas Krebbel d0f4c16feb [PATCH] s390: add oprofile callgraph support
Signed-off-by: Andreas Krebbel <krebbel1@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-01-06 08:33:50 -08:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00