Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 15 2月, 2011 3 次提交
    • R
      oprofile, s390: Rework hwsampler implementation · a0d76247
      由 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: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
      a0d76247
    • H
      oprofile, s390: Enhance OProfile to support System zs hardware sampling feature · 997dbb49
      由 Heinz Graalfs 提交于 
      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: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: NMaran Pakkirisamy <maranp@linux.vnet.ibm.com>
Signed-off-by: NHeinz Graalfs <graalfs@linux.vnet.ibm.com>
Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
      997dbb49
    • H
      oprofile, s390: Add support for hardware based sampling on System z processors · ec6a3df1
      由 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: NMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: NMaran Pakkirisamy <maranp@linux.vnet.ibm.com>
Signed-off-by: NHeinz Graalfs <graalfs@linux.vnet.ibm.com>
Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
      ec6a3df1
  3. 27 1月, 2011 1 次提交
    • A
      ARM: oprofile: Fix backtraces in timer mode · d14dd7e2
      由 Ari Kauppi 提交于 
      Always allow backtraces when using oprofile on ARM, even if a PMU
isn't present. Restores functionality originally introduced in commit
1b7b5698 ("oprofile: Always allow
backtraces on ARM") by Richard Purdie.

It is not that obvious, but there is now only one oprofile_arch_init()
function. So the .backtrace callback is available also in timer mode.

Implemented by removing code and using stubs for oprofile_perf_{init,
exit} provided by <linux/oprofile.h>. This allows cleaning of other
architecture specific implementations too.

Cc: stable@kernel.org # 37.x
Signed-off-by: NAri Kauppi <kauppi@papupata.org>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
      d14dd7e2
  5. 22 1月, 2011 1 次提交
    • S
      xen: p2m: correctly initialize partial p2m leaf · 8e1b4cf2
      由 Stefan Bader 提交于 
      After changing the p2m mapping to a tree by

  commit 58e05027
    xen: convert p2m to a 3 level tree

and trying to boot a DomU with 615MB of memory, the following crash was
observed in the dump:

kernel direct mapping tables up to 26f00000 @ 1ec4000-1fff000
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<c0107397>] xen_set_pte+0x27/0x60
*pdpt = 0000000000000000 *pde = 0000000000000000

Adding further debug statements showed that when trying to set up
pfn=0x26700 the returned mapping was invalid.

pfn=0x266ff calling set_pte(0xc1fe77f8, 0x6b3003)
pfn=0x26700 calling set_pte(0xc1fe7800, 0x3)

Although the last_pfn obtained from the startup info is 0x26700, which
should in turn not be hit, the additional 8MB which are added as extra
memory normally seem to be ok. This lead to looking into the initial
p2m tree construction, which uses the smaller value and assuming that
there is other code handling the extra memory.

When the p2m tree is set up, the leaves are directly pointed to the
array which the domain builder set up. But if the mapping is not on a
boundary that fits into one p2m page, this will result in the last leaf
being only partially valid. And as the invalid entries are not
initialized in that case, things go badly wrong.

I am trying to fix that by checking whether the current leaf is a
complete map and if not, allocate a completely new page and copy only
the valid pointers there. This may not be the most efficient or elegant
solution, but at least it seems to allow me booting DomUs with memory
assignments all over the range.

BugLink: http://bugs.launchpad.net/bugs/686692
[v2: Redid a bit of commit wording and fixed a compile warning]
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      8e1b4cf2
  7. 21 1月, 2011 35 次提交