1. 12 12月, 2011 2 次提交
    • F
      nohz: Allow rcu extended quiescent state handling seperately from tick stop · 2bbb6817
      Frederic Weisbecker 提交于
      It is assumed that rcu won't be used once we switch to tickless
      mode and until we restart the tick. However this is not always
      true, as in x86-64 where we dereference the idle notifiers after
      the tick is stopped.
      
      To prepare for fixing this, add two new APIs:
      tick_nohz_idle_enter_norcu() and tick_nohz_idle_exit_norcu().
      
      If no use of RCU is made in the idle loop between
      tick_nohz_enter_idle() and tick_nohz_exit_idle() calls, the arch
      must instead call the new *_norcu() version such that the arch doesn't
      need to call rcu_idle_enter() and rcu_idle_exit().
      
      Otherwise the arch must call tick_nohz_enter_idle() and
      tick_nohz_exit_idle() and also call explicitly:
      
      - rcu_idle_enter() after its last use of RCU before the CPU is put
      to sleep.
      - rcu_idle_exit() before the first use of RCU after the CPU is woken
      up.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: David Miller <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      2bbb6817
    • F
      nohz: Separate out irq exit and idle loop dyntick logic · 280f0677
      Frederic Weisbecker 提交于
      The tick_nohz_stop_sched_tick() function, which tries to delay
      the next timer tick as long as possible, can be called from two
      places:
      
      - From the idle loop to start the dytick idle mode
      - From interrupt exit if we have interrupted the dyntick
      idle mode, so that we reprogram the next tick event in
      case the irq changed some internal state that requires this
      action.
      
      There are only few minor differences between both that
      are handled by that function, driven by the ts->inidle
      cpu variable and the inidle parameter. The whole guarantees
      that we only update the dyntick mode on irq exit if we actually
      interrupted the dyntick idle mode, and that we enter in RCU extended
      quiescent state from idle loop entry only.
      
      Split this function into:
      
      - tick_nohz_idle_enter(), which sets ts->inidle to 1, enters
      dynticks idle mode unconditionally if it can, and enters into RCU
      extended quiescent state.
      
      - tick_nohz_irq_exit() which only updates the dynticks idle mode
      when ts->inidle is set (ie: if tick_nohz_idle_enter() has been called).
      
      To maintain symmetry, tick_nohz_restart_sched_tick() has been renamed
      into tick_nohz_idle_exit().
      
      This simplifies the code and micro-optimize the irq exit path (no need
      for local_irq_save there). This also prepares for the split between
      dynticks and rcu extended quiescent state logics. We'll need this split to
      further fix illegal uses of RCU in extended quiescent states in the idle
      loop.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: David Miller <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      280f0677
  2. 14 11月, 2011 1 次提交
  3. 11 11月, 2011 2 次提交
    • M
      MIPS: ASID conflict after CPU hotplug · 5c200197
      Maksim Rayskiy 提交于
      I am running SMP Linux 2.6.37-rc1 on BMIPS5000 (single core dual thread)
      and observe some abnormalities when doing system suspend/resume which I
      narrowed down to cpu hotplugging. The suspend brings the second thread
      processor down and then restarts it, after which I see memory corruption
      in userspace. I started digging and found out that problem occurs because
      while doing execve() the child process is getting the same ASID as the
      parent, which obviously corrupts parent's address space.
      
      Further digging showed that activate_mm() calls get_new_mmu_context() to
      get a new ASID, but at this time ASID field in entryHi is 1, and
      asid_cache(cpu) is 0x100 (it was just reset to ASID_FIRST_VERSION when
      the secondary TP was booting).
      
      So, get_new_mmu_context() increments the asid_cache(cpu) value to
      0x101, and thus puts 0x01 into entryHi. The result - ASID field does
      not get changed as it was supposed to.
      
      My solution is very simple - do not reset asid_cache(cpu) on TP warm
      restart.
      
      Patchwork: https://patchwork.linux-mips.org/patch/1797/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      5c200197
    • A
      MIPS: errloongson2_clock: Fix build error by including linux/module.h · 54b2edf4
      Aaro Koskinen 提交于
      Fix the following compilation failure with v3.2-rc1 by including module.h:
      
        CC [M]  arch/mips/kernel/cpufreq/loongson2_clock.o
      arch/mips/kernel/cpufreq/loongson2_clock.c:39:1: error: data definition has no type or storage class [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:39:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Werror=implicit-int]
      arch/mips/kernel/cpufreq/loongson2_clock.c:39:1: error: parameter names (without types) in function declaration [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:51:1: error: data definition has no type or storage class [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:51:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Werror=implicit-int]
      arch/mips/kernel/cpufreq/loongson2_clock.c:51:1: error: parameter names (without types) in function declaration [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:71:1: error: data definition has no type or storage class [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:71:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Werror=implicit-int]
      arch/mips/kernel/cpufreq/loongson2_clock.c:71:1: error: parameter names (without types) in function declaration [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:76:1: error: data definition has no type or storage class [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:76:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Werror=implicit-int]
      arch/mips/kernel/cpufreq/loongson2_clock.c:76:1: error: parameter names (without types) in function declaration [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:82:1: error: data definition has no type or storage class [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:82:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Werror=implicit-int]
      arch/mips/kernel/cpufreq/loongson2_clock.c:82:1: error: parameter names (without types) in function declaration [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:87:1: error: data definition has no type or storage class [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:87:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Werror=implicit-int]
      arch/mips/kernel/cpufreq/loongson2_clock.c:87:1: error: parameter names (without types) in function declaration [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:93:1: error: data definition has no type or storage class [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:93:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Werror=implicit-int]
      arch/mips/kernel/cpufreq/loongson2_clock.c:93:1: error: parameter names (without types) in function declaration [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:131:1: error: data definition has no type or storage class [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:131:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Werror=implicit-int]
      arch/mips/kernel/cpufreq/loongson2_clock.c:131:1: error: parameter names (without types) in function declaration [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:147:1: error: data definition has no type or storage class [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:147:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Werror=implicit-int]
      arch/mips/kernel/cpufreq/loongson2_clock.c:147:1: error: parameter names (without types) in function declaration [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:166:1: error: data definition has no type or storage class [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:166:1: error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' [-Werror=implicit-int]
      arch/mips/kernel/cpufreq/loongson2_clock.c:166:1: error: parameter names (without types) in function declaration [-Werror]
      arch/mips/kernel/cpufreq/loongson2_clock.c:168:15: error: expected declaration specifiers or '...' before string constant
      arch/mips/kernel/cpufreq/loongson2_clock.c:169:20: error: expected declaration specifiers or '...' before string constant
      arch/mips/kernel/cpufreq/loongson2_clock.c:170:16: error: expected declaration specifiers or '...' before string constant
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      To: linux-mips@linux-mips.org
      To: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/2922/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      54b2edf4
  4. 09 11月, 2011 2 次提交
  5. 01 11月, 2011 4 次提交
  6. 25 10月, 2011 5 次提交
  7. 20 10月, 2011 1 次提交
  8. 02 10月, 2011 1 次提交
  9. 21 9月, 2011 5 次提交
  10. 17 9月, 2011 2 次提交
  11. 27 8月, 2011 1 次提交
  12. 27 7月, 2011 1 次提交
  13. 26 7月, 2011 3 次提交
  14. 24 7月, 2011 1 次提交
  15. 22 7月, 2011 1 次提交
  16. 21 7月, 2011 1 次提交
  17. 16 7月, 2011 1 次提交
  18. 01 7月, 2011 3 次提交
    • P
      perf, arch: Add generic NODE cache events · 89d6c0b5
      Peter Zijlstra 提交于
      Add a NODE level to the generic cache events which is used to measure
      local vs remote memory accesses. Like all other cache events, an
      ACCESS is HIT+MISS, if there is no way to distinguish between reads
      and writes do reads only etc..
      
      The below needs filling out for !x86 (which I filled out with
      unsupported events).
      
      I'm fairly sure ARM can leave it like that since it doesn't strike me as
      an architecture that even has NUMA support. SH might have something since
      it does appear to have some NUMA bits.
      
      Sparc64, PowerPC and MIPS certainly want a good look there since they
      clearly are NUMA capable.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: David Miller <davem@davemloft.net>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1303508226.4865.8.camel@laptopSigned-off-by: NIngo Molnar <mingo@elte.hu>
      89d6c0b5
    • P
      perf: Remove the nmi parameter from the swevent and overflow interface · a8b0ca17
      Peter Zijlstra 提交于
      The nmi parameter indicated if we could do wakeups from the current
      context, if not, we would set some state and self-IPI and let the
      resulting interrupt do the wakeup.
      
      For the various event classes:
      
        - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
          the PMI-tail (ARM etc.)
        - tracepoint: nmi=0; since tracepoint could be from NMI context.
        - software: nmi=[0,1]; some, like the schedule thing cannot
          perform wakeups, and hence need 0.
      
      As one can see, there is very little nmi=1 usage, and the down-side of
      not using it is that on some platforms some software events can have a
      jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).
      
      The up-side however is that we can remove the nmi parameter and save a
      bunch of conditionals in fast paths.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Michael Cree <mcree@orcon.net.nz>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Eric B Munson <emunson@mgebm.net>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jason Wessel <jason.wessel@windriver.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      a8b0ca17
    • T
      mips: Use common i8253 clockevent · 2d02612f
      Thomas Gleixner 提交于
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: John Stultz <john.stultz@linaro.org>
      Link: http://lkml.kernel.org/r/20110609130622.133068765@linutronix.de
      2d02612f
  19. 15 6月, 2011 1 次提交
  20. 09 6月, 2011 2 次提交