Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 158
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 11 9月, 2009 4 次提交
    • P
      powerpc/perf_counters: Reduce stack usage of power_check_constraints · e51ee31e
      由 Paul Mackerras 提交于 
      Michael Ellerman reported stack-frame size warnings being produced
for power_check_constraints(), which uses an 8*8 array of u64 and
two 8*8 arrays of unsigned long, which are currently allocated on the
stack, along with some other smaller variables.  These arrays come
to 1.5kB on 64-bit or 1kB on 32-bit, which is a bit too much for the
stack.

This fixes the problem by putting these arrays in the existing
per-cpu cpu_hw_counters struct.  This is OK because two of the call
sites have interrupts disabled already; for the third call site we
use get_cpu_var, which disables preemption, so we know we won't
get a context switch while we're in power_check_constraints().
Note that power_check_constraints() can be called during context
switch but is not called from interrupts.
Reported-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Cc: <stable@kernel.org)
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      e51ee31e
    • P
      powerpc: Fix bug where perf_counters breaks oprofile · a6dbf93a
      由 Paul Mackerras 提交于 
      Currently there is a bug where if you use oprofile on a pSeries
machine, then use perf_counters, then use oprofile again, oprofile
will not work correctly; it will lose the PMU configuration the next
time the hypervisor does a partition context switch, and thereafter
won't count anything.

Maynard Johnson identified the sequence causing the problem:
- oprofile setup calls ppc_enable_pmcs(), which calls
  pseries_lpar_enable_pmcs, which tells the hypervisor that we want
  to use the PMU, and sets the "PMU in use" flag in the lppaca.
  This flag tells the hypervisor whether it needs to save and restore
  the PMU config.
- The perf_counter code sets and clears the "PMU in use" flag directly
  as it context-switches the PMU between tasks, and leaves it clear
  when it finishes.
- oprofile setup, called for a new oprofile run, calls ppc_enable_pmcs,
  which does nothing because it has already been called.  In particular
  it doesn't set the "PMU in use" flag.

This fixes the problem by arranging for ppc_enable_pmcs to always set
the "PMU in use" flag.  It makes the perf_counter code call
ppc_enable_pmcs also rather than calling the lower-level function
directly, and removes the setting of the "PMU in use" flag from
pseries_lpar_enable_pmcs, since that is now done in its caller.

This also removes the declaration of pasemi_enable_pmcs because it
isn't defined anywhere.
Reported-by: NMaynard Johnson <mpjohn@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Cc: <stable@kernel.org)
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      a6dbf93a
    • K
      powerpc/85xx: Fix SMP compile error and allow NULL for smp_ops · 757cbd46
      由 Kumar Gala 提交于 
      The following commit introduced a compile error since it removed
the implementation of smp_85xx_basic_setup:

commit 77c0a700
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date:   Fri Aug 28 14:25:04 2009 +1000

    powerpc: Properly start decrementer on BookE secondary CPUs

Make it so that smp_ops probe() and setup_cpu() can be set to NULL.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      757cbd46
    • W
      powerpc/irq: Improve nanodoc · 8708d002
      由 Wolfram Sang 提交于 
      The OF helpers look like nanodoc but are missing the header. Fix this and a
typo (s/nad/and/) while we are here.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8708d002
  3. 02 9月, 2009 6 次提交
  5. 31 8月, 2009 6 次提交
  7. 28 8月, 2009 21 次提交
  9. 27 8月, 2009 3 次提交
    • B
      Merge commit 'kumar/next' into next · 3c2ee2d9
      由 Benjamin Herrenschmidt 提交于
      3c2ee2d9
    • G
      powerpc/pseries: Reduce the polling interval in __cpu_up() · 67764263
      由 Gautham R Shenoy 提交于 
      Time time taken for a single cpu online operation on a pseries machine
is as follows:
Dedicated LPAR (POWER6): ~220ms.
Shared LPAR (POWER5)   : ~240ms.

Of this time, approximately 200ms is taken up by __cpu_up(). This is because
we poll every 200ms to check if the new cpu has notified it's presence
through the cpu_callin_map. We repeat this operation until the new cpu sets
the value in cpu_callin_map or 5 seconds elapse, whichever comes earlier.

However, using completion_structs instead of polling loops,
the time taken by the new processor to indicate it's presence has
found to be less than 1ms on pseries. This method however may not
work on all powerpc platforms due to the time-base synchronization code.

Keeping this in mind, we could reduce msleep polling interval from
200ms to 1ms while retaining the 5 second timeout.

With this, the time taken for a cpu online operation changes as follows:
Dedicated LPAR (POWER6): 20-25ms.
Shared LPAR (POWER5)   : 60-80ms.

In both these cases, it was found that the code polls through the loop
only once indicating that 1ms is a reasonable value, atleast on pseries.

The code needs testing on other powerpc platforms.
Signed-off-by: NGautham R Shenoy <ego@in.ibm.com>
Acked-by: NJoel Schopp <jschopp@austin.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      67764263
    • B
      powerpc: Remove SMP warning from PowerMac cpufreq · 6fdc31a2
      由 Bastian Blank 提交于 
      On Thu, Aug 13, 2009 at 04:14:58PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2009-08-11 at 11:39 +0200, Bastian Blank wrote:
> > This patch just disables this driver on SMP kernels, as it is obviously
> > not supported.
> Why not remove the #error instead ? :-) I don't think it's still
> meaningful, especially since we use the timebase for delays nowadays
> which doesn't depend on the CPU frequency...

Your call. Take this one:

The build of a PowerMac 32bit kernel currently fails with

error: #warning "WARNING, CPUFREQ not recommended on SMP kernels"

Thie patch removes the not longer applicable SMP warning from the
PowerMac cpufreq code.
Signed-off-by: NBastian Blank <waldi@debian.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      6fdc31a2