07 Jan, 2012

1 commit

  • * 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (106 commits)
    perf kvm: Fix copy & paste error in description
    perf script: Kill script_spec__delete
    perf top: Fix a memory leak
    perf stat: Introduce get_ratio_color() helper
    perf session: Remove impossible condition check
    perf tools: Fix feature-bits rework fallout, remove unused variable
    perf script: Add generic perl handler to process events
    perf tools: Use for_each_set_bit() to iterate over feature flags
    perf tools: Unify handling of features when writing feature section
    perf report: Accept fifos as input file
    perf tools: Moving code in some files
    perf tools: Fix out-of-bound access to struct perf_session
    perf tools: Continue processing header on unknown features
    perf tools: Improve macros for struct feature_ops
    perf: builtin-record: Document and check that mmap_pages must be a power of two.
    perf: builtin-record: Provide advice if mmap'ing fails with EPERM.
    perf tools: Fix truncated annotation
    perf script: look up thread using tid instead of pid
    perf tools: Look up thread names for system wide profiling
    perf tools: Fix comm for processes with named threads
    ...

    Linus Torvalds
     

20 Dec, 2011

2 commits


07 Dec, 2011

2 commits

  • 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 configured using the user space tools with only little
    modifications.

    With the patch by default new cpu_types (s390/z10, s390/z196) are
    returned in order to indicate that we are running a CPU which provides
    the hardware sampling facility. Existing user space tools will
    complain about an unknown cpu type. In order to be compatible with
    existing user space tools the `cpu_type' module parameter has been
    added. Setting the parameter to `timer' will force the module to
    return `timer' as cpu_type. The module will still try to use hardware
    sampling if available and the hwsampling virtual filesystem will be
    also be available for configuration. So this has a different effect
    than using the generic oprofile module parameter `timer=1'.

    If the basic mode sampling is enabled on the machine and the
    cpu_type=timer parameter is not used the kernel module will provide
    the following virtual filesystem:

    /dev/oprofile/0/enabled
    /dev/oprofile/0/event
    /dev/oprofile/0/count
    /dev/oprofile/0/unit_mask
    /dev/oprofile/0/kernel
    /dev/oprofile/0/user

    In the counter file system only the values of 'enabled', 'count',
    'kernel', and 'user' are evaluated by the kernel module. Everything
    else must contain fixed values.

    The 'event' value only supports a single event - HWSAMPLING with value
    0.

    The 'count' value specifies the hardware sampling rate as it is passed
    to the CPU measurement facility.

    The 'kernel' and 'user' flags can now be used to filter for samples
    when using hardware sampling.

    Additionally also the following file will be created:
    /dev/oprofile/timer/enabled

    This will always be the inverted value of /dev/oprofile/0/enabled. 0
    is not accepted without hardware sampling.

    Signed-off-by: Andreas Krebbel
    Signed-off-by: Robert Richter

    Andreas Krebbel
     
  • Removing remainings of oprofile_timer_exit() completly.

    Signed-off-by: Robert Richter

    Robert Richter
     

30 Oct, 2011

1 commit


11 Jul, 2011

1 commit


22 Jun, 2011

2 commits

  • The sampling interval for the hardware sampler is specified in cycles.
    (see SA23-2260-01 The Load-Program-Parameter and the CPU-Measurement
    Facilities)
    The current default value will therefore result in millions of samples.
    This patch changes the default sampling interval to 4M, which will
    result in ~1500 samples per second on a z196 reducing the overhead
    of sampling.

    Signed-off-by: Christian Borntraeger
    Signed-off-by: Martin Schwidefsky

    Christian Borntraeger
     
  • On specific configurations with hwsampler opcontrol --start returns an
    error on "echo 1 >/dev/oprofile/enable". Turns out that the hw sampling
    interval is not checked against the hardware limits.

    Signed-off-by: Christian Borntraeger
    Signed-off-by: Martin Schwidefsky

    Christian Borntraeger
     

20 Jun, 2011

1 commit


26 May, 2011

2 commits


23 May, 2011

4 commits


10 May, 2011

1 commit

  • oprofile_min_interval and oprofile_max_interval are unsigned, checking
    for negative values doesn't work. Change hwsampler_query_min_interval
    and hwsampler_query_max_interval to return an unsigned long and
    check for a zero value instead.

    Reported-by: Nicolas Kaiser
    Acked-by: Robert Richter
    Signed-off-by: Martin Schwidefsky

    Martin Schwidefsky
     

04 Apr, 2011

1 commit


23 Mar, 2011

1 commit


16 Mar, 2011

2 commits


15 Feb, 2011

4 commits

  • Fixes the following section mismatch:

    Section mismatch in reference from the variable hws_cpu_notifier to the function .cpuinit.text:hws_cpu_callback()

    Acked-by: Heiko Carstens
    Signed-off-by: Robert Richter

    Robert Richter
     
  • This patch is a rework of the hwsampler oprofile implementation that
    has been applied recently. Now there are less non-architectural
    changes. The only changes are:

    * introduction of oprofile_add_ext_hw_sample(), and
    * removal of section attributes of oprofile_timer_init/_exit().

    To setup hwsampler for oprofile we need to modify start()/stop()
    callbacks and additional hwsampler control files in oprofilefs. We do
    not reinitialize the timer or hwsampler mode by restarting calling
    init/exit() anymore, instead hwsampler_running is used to switch the
    mode directly in oprofile_hwsampler_start/_stop(). For locking reasons
    there is also hwsampler_file that reflects the value in oprofilefs.

    The overall diffstat of the oprofile s390 hwsampler implemenation
    shows the low impact to non-architectural code:

    arch/Kconfig | 3 +
    arch/s390/Kconfig | 1 +
    arch/s390/oprofile/Makefile | 2 +-
    arch/s390/oprofile/hwsampler.c | 1256 ++++++++++++++++++++++++++++++++++
    arch/s390/oprofile/hwsampler.h | 113 +++
    arch/s390/oprofile/hwsampler_files.c | 162 +++++
    arch/s390/oprofile/init.c | 6 +-
    drivers/oprofile/cpu_buffer.c | 24 +-
    drivers/oprofile/timer_int.c | 4 +-
    include/linux/oprofile.h | 7 +
    10 files changed, 1567 insertions(+), 11 deletions(-)

    Acked-by: Heiko Carstens
    Signed-off-by: Robert Richter

    Robert Richter
     
  • 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
    Signed-off-by: Maran Pakkirisamy
    Signed-off-by: Heinz Graalfs
    Acked-by: Heiko Carstens
    Signed-off-by: Robert Richter

    Heinz Graalfs
     
  • 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
    Signed-off-by: Maran Pakkirisamy
    Signed-off-by: Heinz Graalfs
    Acked-by: Heiko Carstens
    Signed-off-by: Robert Richter

    Heinz Graalfs
     

20 Oct, 2007

1 commit

  • Quoting Randy:

    "It seems sad that this patch sources Kconfig.marker, a 7-line file,
    20-something times. Yes, you (we) don't want to put those 7 lines into
    20-something different files, so sourcing is the right thing.

    However, what you did for avr32 seems more on the right track to me: make
    _one_ Instrumentation support menu that includes PROFILING, OPROFILE, KPROBES,
    and MARKERS and then use (source) that in all of the arches."

    Signed-off-by: Mathieu Desnoyers
    Acked-by: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mathieu Desnoyers
     

07 Jan, 2006

1 commit


17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds