summaryrefslogtreecommitdiff
path: root/arch/s390/oprofile/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2011-03-23[S390] oprofile: disable hw sampling for CONFIG_32BITHeiko Carstens1-1/+2
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-16oprofile, s390: Remove hwsampler_files.c and merge it into init.cHeinz Graalfs1-1/+1
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-02-15oprofile, s390: Enhance OProfile to support System zs hardware sampling featureHeinz Graalfs1-1/+1
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-15oprofile, s390: Add support for hardware based sampling on System z processorsHeinz Graalfs1-1/+1
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>
2006-01-06[PATCH] s390: add oprofile callgraph supportAndreas Krebbel1-1/+1
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>
2005-04-17Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+9
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!