1. 21 10月, 2010 1 次提交
    • A
      BKL: introduce CONFIG_BKL. · 6de5bd12
      Arnd Bergmann 提交于
      With all the patches we have queued in the BKL removal tree, only a
      few dozen modules are left that actually rely on the BKL, and even
      there are lots of low-hanging fruit. We need to decide what to do
      about them, this patch illustrates one of the options:
      
      Every user of the BKL is marked as 'depends on BKL' in Kconfig,
      and the CONFIG_BKL becomes a user-visible option. If it gets
      disabled, no BKL using module can be built any more and the BKL
      code itself is compiled out.
      
      The one exception is file locking, which is practically always
      enabled and does a 'select BKL' instead. This effectively forces
      CONFIG_BKL to be enabled until we have solved the fs/lockd
      mess and can apply the patch that removes the BKL from fs/locks.c.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      6de5bd12
  2. 06 10月, 2010 1 次提交
  3. 24 9月, 2010 1 次提交
  4. 01 9月, 2010 1 次提交
    • S
      tracing/lockdep: Fix dependency of TRACE_IRQFLAGS · 46b93b74
      Steven Rostedt 提交于
      When CONFIG_IRQSOFF_TRACER is set and CONFIG_PROVE_LOCKING is not, we
      get the following error:
      
      $  make oldconfig
      scripts/kconfig/conf --oldconfig arch/x86/Kconfig
      warning: (IRQSOFF_TRACER && TRACING_SUPPORT && FTRACE && TRACE_IRQFLAGS_SUPPORT && !ARCH_USES_GETTIMEOFFSET) selects TRACE_IRQFLAGS which has unmet direct dependencies (DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && PROVE_LOCKING)
      warning: (IRQSOFF_TRACER && TRACING_SUPPORT && FTRACE && TRACE_IRQFLAGS_SUPPORT && !ARCH_USES_GETTIMEOFFSET) selects TRACE_IRQFLAGS which has unmet direct dependencies (DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && PROVE_LOCKING)
      
      This is because IRQSOFF_TRACER selects TRACE_IRQFLAGS but TRACE_IRQFLAGS
      has PROVE_LOCKING as a dependency. This code is incorrect, and
      this patch changes the TRACE_IRQFLAGS to be just a simple bool that
      does not depend or select anything. Instead both IRQSOFF_TRACER and
      PROVE_LOCKING select it.
      Reported-by: NRichard Kennedy <richard@rsk.demon.co.uk>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      46b93b74
  5. 20 8月, 2010 3 次提交
    • P
      rcu: Allow RCU CPU stall warnings to be off at boot, but manually enablable · 910b1b7e
      Paul E. McKenney 提交于
      Currently, if RCU CPU stall warnings are enabled, they are enabled
      immediately upon boot.  They can be manually disabled via /sys (and
      also re-enabled via /sys), and are automatically disabled upon panic.
      However, some users need RCU CPU stalls to be disabled at boot time,
      but to be enabled without rebuilding/rebooting.  For example, someone
      running a real-time application in production might not want the
      additional latency of RCU CPU stall detection in normal operation, but
      might need to enable it at any point for fault isolation purposes.
      
      This commit therefore provides a new CONFIG_RCU_CPU_STALL_DETECTOR_RUNNABLE
      kernel configuration parameter that maintains the current behavior
      (enable at boot) by default, but allows a kernel to be configured
      with RCU CPU stall detection built into the kernel, but disabled at
      boot time.
      Requested-by: NClark Williams <williams@redhat.com>
      Requested-by: NJohn Kacur <jkacur@redhat.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      910b1b7e
    • P
      rcu: make CPU stall warning timeout configurable · b163760e
      Paul E. McKenney 提交于
      Also set the default to 60 seconds, up from the previous hard-coded timeout
      of 10 seconds.  This allows people who care to set short timeouts, while
      avoiding people with unusual configurations (make randconfig!!!) from being
      bothered with spurious CPU stall warnings.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      b163760e
    • P
      rcu: define __rcu address space modifier for sparse · ca5ecddf
      Paul E. McKenney 提交于
      This commit provides definitions for the __rcu annotation defined earlier.
      This annotation permits sparse to check for correct use of RCU-protected
      pointers.  If a pointer that is annotated with __rcu is accessed
      directly (as opposed to via rcu_dereference(), rcu_assign_pointer(),
      or one of their variants), sparse can be made to complain.  To enable
      such complaints, use the new default-disabled CONFIG_SPARSE_RCU_POINTER
      kernel configuration option.  Please note that these sparse complaints are
      intended to be a debugging aid, -not- a code-style-enforcement mechanism.
      
      There are special rcu_dereference_protected() and rcu_access_pointer()
      accessors for use when RCU read-side protection is not required, for
      example, when no other CPU has access to the data structure in question
      or while the current CPU hold the update-side lock.
      
      This patch also updates a number of docbook comments that were showing
      their age.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Christopher Li <sparse@chrisli.org>
      Reviewed-by: NJosh Triplett <josh@joshtriplett.org>
      ca5ecddf
  6. 17 8月, 2010 1 次提交
    • R
      latencytop: Fix kconfig dependency warnings · 625fdcaa
      Randy Dunlap 提交于
      warning: (LATENCYTOP && HAVE_LATENCYTOP_SUPPORT) selects
      SCHED_DEBUG which has unmet direct dependencies (DEBUG_KERNEL &&
      PROC_FS) warning: (LATENCYTOP && HAVE_LATENCYTOP_SUPPORT) selects
      SCHEDSTATS which has unmet direct dependencies (DEBUG_KERNEL && PROC_FS)
      
      Add depends on STACKTRACE_SUPPORT for 'select STACKTRACE'.
      Add depends on PROC_FS since that is where the output goes.
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      LKML-Reference: <20100812123121.a7c99cde.randy.dunlap@oracle.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      625fdcaa
  7. 06 8月, 2010 1 次提交
    • R
      debugfs: no longer needs to depend on SYSFS · c462e8cd
      Randy Dunlap 提交于
      debugfs no longer uses 'kernel_subsys' (which is gone), and other
      kernel/ksysfs.c code is always built, so DEBUG_FS does not need
      to depend on SYSFS.
      
      Fixes this kconfig warning:
      
      warning: (TREE_RCU_TRACE || AMD_IOMMU_STATS && AMD_IOMMU || MTD_UBI_DEBUG && MTD && SYSFS && MTD_UBI || UBIFS_FS_DEBUG && MISC_FILESYSTEMS && UBIFS_FS || DEBUG_KMEMLEAK && DEBUG_KERNEL && EXPERIMENTAL && !MEMORY_HOTPLUG && (X86 || ARM || PPC || S390 || SPARC64 || SUPERH || MICROBLAZE) && SYSFS || TRACING || X86_PTDUMP && DEBUG_KERNEL || BLK_DEV_IO_TRACE && TRACING_SUPPORT && FTRACE && SYSFS && BLOCK) selects DEBUG_FS which has unmet direct dependencies (SYSFS)
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c462e8cd
  8. 04 8月, 2010 1 次提交
  9. 21 7月, 2010 1 次提交
  10. 19 7月, 2010 1 次提交
  11. 14 7月, 2010 1 次提交
    • A
      Kbuild: Add option to set -femit-struct-debug-baseonly · d6f4ceb7
      Andi Kleen 提交于
      Newer gcc has a -femit-struct-debug-baseonly option that dramatically
      reduces the size of object files with debug info. What it does
      is to only emit type information for structures when the structures
      are defined in the same file or in a header file.
      
      This means the type information for most headers are not included.
      This is not good when the type information is actually
      needed (e.g. with kgdb or systemtap)
      
      But often kernel hackers only care about line numbers and don't
      need all the type information anyways. In this case setting
      the option can be a big win:
      
      A build dir for a specific x86-64 configuration with gcc 4.5
      shrunk from 2.3G to 1.2G. The compilation was also nearly a minute
      faster.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      [mmarek: reformatted help text]
      Signed-off-by: NMichal Marek <mmarek@suse.cz>
      d6f4ceb7
  12. 15 6月, 2010 1 次提交
    • M
      tree/tiny rcu: Add debug RCU head objects · 551d55a9
      Mathieu Desnoyers 提交于
      Helps finding racy users of call_rcu(), which results in hangs because list
      entries are overwritten and/or skipped.
      
      Changelog since v4:
      - Bissectability is now OK
      - Now generate a WARN_ON_ONCE() for non-initialized rcu_head passed to
        call_rcu(). Statically initialized objects are detected with
        object_is_static().
      - Rename rcu_head_init_on_stack to init_rcu_head_on_stack.
      - Remove init_rcu_head() completely.
      
      Changelog since v3:
      - Include comments from Lai Jiangshan
      
      This new patch version is based on the debugobjects with the newly introduced
      "active state" tracker.
      
      Non-initialized entries are all considered as "statically initialized". An
      activation fixup (triggered by call_rcu()) takes care of performing the debug
      object initialization without issuing any warning. Since we cannot increase the
      size of struct rcu_head, I don't see much room to put an identifier for
      statically initialized rcu_head structures. So for now, we have to live without
      "activation without explicit init" detection. But the main purpose of this debug
      option is to detect double-activations (double call_rcu() use of a rcu_head
      before the callback is executed), which is correctly addressed here.
      
      This also detects potential internal RCU callback corruption, which would cause
      the callbacks to be executed twice.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      CC: akpm@linux-foundation.org
      CC: mingo@elte.hu
      CC: laijs@cn.fujitsu.com
      CC: dipankar@in.ibm.com
      CC: josh@joshtriplett.org
      CC: dvhltc@us.ibm.com
      CC: niv@us.ibm.com
      CC: tglx@linutronix.de
      CC: peterz@infradead.org
      CC: rostedt@goodmis.org
      CC: Valdis.Kletnieks@vt.edu
      CC: dhowells@redhat.com
      CC: eric.dumazet@gmail.com
      CC: Alexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: NLai Jiangshan <laijs@cn.fujitsu.com>
      551d55a9
  13. 28 5月, 2010 1 次提交
  14. 25 5月, 2010 1 次提交
  15. 19 5月, 2010 1 次提交
  16. 16 5月, 2010 2 次提交
    • F
      lockup_detector: Introduce CONFIG_HARDLOCKUP_DETECTOR · 23637d47
      Frederic Weisbecker 提交于
      This new config is deemed to simplify even more the lockup detector
      dependencies and can make it easier to bring a smooth sorting
      between archs that support the new generic lockup detector and those
      that still have their own, especially for those that are in the
      middle of this migration.
      
      Instead of checking whether we have CONFIG_LOCKUP_DETECTOR +
      CONFIG_PERF_EVENTS_NMI each time an arch wants to know if it needs
      to build its own lockup detector, take a shortcut with this new
      config. It is enabled only if the hardlockup detection part of
      the whole lockup detector is on.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      23637d47
    • F
      lockup_detector: Update some config · e16bb1d7
      Frederic Weisbecker 提交于
      We kept CONFIG_DETECT_SOFTLOCKUP around for compatibility with
      older configs. But it was enabled by default if CONFIG_DEBUG_KERNEL.
      
      So if we want to enable CONFIG_LOCKUP_DETECTOR on configs that had
      CONFIG_DETECT_SOFTLOCKUP, all we need is to have the same enabling
      by default if CONFIG_DEBUG_KERNEL. We can then remove
      CONFIG_DETECT_SOFTLOCKUP directly.
      
      So tag CONFIG_LOCKUP_DETECTOR as default y. This is what we want for
      most serious kernel debugging anyway.
      
      And also forbid the lockup detector in S390 as it was for the
      previous softlockup detector, event though the true reason for that
      is not outlined.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      e16bb1d7
  17. 13 5月, 2010 2 次提交
    • F
      lockup_detector: Make BOOTPARAM_SOFTLOCKUP_PANIC depend on LOCKUP_DETECTOR · 89d7ce2a
      Frederic Weisbecker 提交于
      Panic on softlockups was still depending on the softlockup detector.
      But the latter has been merged into the lockup detector now.
      
      Let's update this config dependency.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      89d7ce2a
    • D
      lockup_detector: Combine nmi_watchdog and softlockup detector · 58687acb
      Don Zickus 提交于
      The new nmi_watchdog (which uses the perf event subsystem) is very
      similar in structure to the softlockup detector.  Using Ingo's
      suggestion, I combined the two functionalities into one file:
      kernel/watchdog.c.
      
      Now both the nmi_watchdog (or hardlockup detector) and softlockup
      detector sit on top of the perf event subsystem, which is run every
      60 seconds or so to see if there are any lockups.
      
      To detect hardlockups, cpus not responding to interrupts, I
      implemented an hrtimer that runs 5 times for every perf event
      overflow event.  If that stops counting on a cpu, then the cpu is
      most likely in trouble.
      
      To detect softlockups, tasks not yielding to the scheduler, I used the
      previous kthread idea that now gets kicked every time the hrtimer fires.
      If the kthread isn't being scheduled neither is anyone else and the
      warning is printed to the console.
      
      I tested this on x86_64 and both the softlockup and hardlockup paths
      work.
      
      V2:
      - cleaned up the Kconfig and softlockup combination
      - surrounded hardlockup cases with #ifdef CONFIG_PERF_EVENTS_NMI
      - seperated out the softlockup case from perf event subsystem
      - re-arranged the enabling/disabling nmi watchdog from proc space
      - added cpumasks for hardlockup failure cases
      - removed fallback to soft events if no PMU exists for hard events
      
      V3:
      - comment cleanups
      - drop support for older softlockup code
      - per_cpu cleanups
      - completely remove software clock base hardlockup detector
      - use per_cpu masking on hard/soft lockup detection
      - #ifdef cleanups
      - rename config option NMI_WATCHDOG to LOCKUP_DETECTOR
      - documentation additions
      
      V4:
      - documentation fixes
      - convert per_cpu to __get_cpu_var
      - powerpc compile fixes
      
      V5:
      - split apart warn flags for hard and soft lockups
      
      TODO:
      - figure out how to make an arch-agnostic clock2cycles call
        (if possible) to feed into perf events as a sample period
      
      [fweisbec: merged conflict patch]
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Cyrill Gorcunov <gorcunov@gmail.com>
      Cc: Eric Paris <eparis@redhat.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      LKML-Reference: <1273266711-18706-2-git-send-email-dzickus@redhat.com>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      58687acb
  18. 11 5月, 2010 2 次提交
  19. 13 4月, 2010 1 次提交
  20. 07 4月, 2010 1 次提交
  21. 25 3月, 2010 1 次提交
  22. 07 3月, 2010 1 次提交
  23. 01 3月, 2010 1 次提交
    • I
      nmi_watchdog: Turn it off by default · c99c30fe
      Ingo Molnar 提交于
      It was nice to enable it by default for testing - but before we
      push it upstream we want it to be off - so that people can
      opt-in gradually.
      
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: peterz@infradead.org
      Cc: gorcunov@gmail.com
      Cc: aris@redhat.com
      LKML-Reference: <1266880143-24943-1-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      c99c30fe
  24. 28 2月, 2010 2 次提交
    • F
      perf: Remove pointless breakpoint union · dd8b1cf6
      Frederic Weisbecker 提交于
      Remove pointless union in the breakpoint field of hw_perf_event.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      dd8b1cf6
    • H
      perf lock: Fix and add misc documentally things · 84c6f88f
      Hitoshi Mitake 提交于
      I've forgot to add 'perf lock' line to command-list.txt,
      so users of perf could not find perf lock when they type 'perf'.
      
      Fixing command-list.txt requires document
      (tools/perf/Documentation/perf-lock.txt).
      But perf lock is too much "under construction" to write a
      stable document, so this is something like pseudo document for now.
      
      And I wrote description of perf lock at help section of
      CONFIG_LOCK_STAT, this will navigate users of lock trace events.
      Signed-off-by: NHitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      LKML-Reference: <1265267295-8388-1-git-send-email-mitake@dcl.info.waseda.ac.jp>
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      84c6f88f
  25. 26 2月, 2010 1 次提交
  26. 25 2月, 2010 2 次提交
    • P
      rcu: Add RCU_CPU_STALL_VERBOSE to dump detailed per-task information · 1ed509a2
      Paul E. McKenney 提交于
      When RCU detects a grace-period stall, it currently just prints
      out the PID of any tasks doing the stalling.  This patch adds
      RCU_CPU_STALL_VERBOSE, which enables the more-verbose reporting
      from sched_show_task().
      Suggested-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: laijs@cn.fujitsu.com
      Cc: dipankar@in.ibm.com
      Cc: mathieu.desnoyers@polymtl.ca
      Cc: josh@joshtriplett.org
      Cc: dvhltc@us.ibm.com
      Cc: niv@us.ibm.com
      Cc: peterz@infradead.org
      Cc: rostedt@goodmis.org
      Cc: Valdis.Kletnieks@vt.edu
      Cc: dhowells@redhat.com
      LKML-Reference: <1266887105-1528-21-git-send-email-paulmck@linux.vnet.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1ed509a2
    • P
      rcu: Introduce lockdep-based checking to RCU read-side primitives · 632ee200
      Paul E. McKenney 提交于
      Inspection is proving insufficient to catch all RCU misuses,
      which is understandable given that rcu_dereference() might be
      protected by any of four different flavors of RCU (RCU, RCU-bh,
      RCU-sched, and SRCU), and might also/instead be protected by any
      of a number of locking primitives. It is therefore time to
      enlist the aid of lockdep.
      
      This set of patches is inspired by earlier work by Peter
      Zijlstra and Thomas Gleixner, and takes the following approach:
      
      o	Set up separate lockdep classes for RCU, RCU-bh, and RCU-sched.
      
      o	Set up separate lockdep classes for each instance of SRCU.
      
      o	Create primitives that check for being in an RCU read-side
      	critical section.  These return exact answers if lockdep is
      	fully enabled, but if unsure, report being in an RCU read-side
      	critical section.  (We want to avoid false positives!)
      	The primitives are:
      
      	For RCU: rcu_read_lock_held(void)
      
      	For RCU-bh: rcu_read_lock_bh_held(void)
      
      	For RCU-sched: rcu_read_lock_sched_held(void)
      
      	For SRCU: srcu_read_lock_held(struct srcu_struct *sp)
      
      o	Add rcu_dereference_check(), which takes a second argument
      	in which one places a boolean expression based on the above
      	primitives and/or lockdep_is_held().
      
      o	A new kernel configuration parameter, CONFIG_PROVE_RCU, enables
      	rcu_dereference_check().  This depends on CONFIG_PROVE_LOCKING,
      	and should be quite helpful during the transition period while
      	CONFIG_PROVE_RCU-unaware patches are in flight.
      
      The existing rcu_dereference() primitive does no checking, but
      upcoming patches will change that.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: laijs@cn.fujitsu.com
      Cc: dipankar@in.ibm.com
      Cc: mathieu.desnoyers@polymtl.ca
      Cc: josh@joshtriplett.org
      Cc: dvhltc@us.ibm.com
      Cc: niv@us.ibm.com
      Cc: peterz@infradead.org
      Cc: rostedt@goodmis.org
      Cc: Valdis.Kletnieks@vt.edu
      Cc: dhowells@redhat.com
      LKML-Reference: <1266887105-1528-1-git-send-email-paulmck@linux.vnet.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      632ee200
  27. 14 2月, 2010 1 次提交
  28. 09 2月, 2010 1 次提交
    • I
      nmi_watchdog: Only enable on x86 for now · 8e7672cd
      Ingo Molnar 提交于
      It wont even build on other platforms just yet - so restrict it
      to x86 for now.
      
      Cc: Don Zickus <dzickus@redhat.com>
      Cc: gorcunov@gmail.com
      Cc: aris@redhat.com
      Cc: peterz@infradead.org
      LKML-Reference: <1265424425-31562-4-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8e7672cd
  29. 08 2月, 2010 1 次提交
    • D
      nmi_watchdog: Config option to enable new nmi_watchdog · 84e478c6
      Don Zickus 提交于
      These are the bits that enable the new nmi_watchdog and safely
      isolate the old nmi_watchdog.  Only one or the other can run,
      not both at the same time.
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: gorcunov@gmail.com
      Cc: aris@redhat.com
      Cc: peterz@infradead.org
      LKML-Reference: <1265424425-31562-4-git-send-email-dzickus@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      84e478c6
  30. 27 1月, 2010 1 次提交
  31. 16 1月, 2010 1 次提交
    • P
      rcu: 1Q2010 update for RCU documentation · 4c54005c
      Paul E. McKenney 提交于
      Add expedited functions.  Review documentation and update
      obsolete verbiage.  Also fix the advice for the RCU CPU-stall
      kernel configuration parameter, and document RCU CPU-stall
      warnings.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: laijs@cn.fujitsu.com
      Cc: dipankar@in.ibm.com
      Cc: mathieu.desnoyers@polymtl.ca
      Cc: josh@joshtriplett.org
      Cc: dvhltc@us.ibm.com
      Cc: niv@us.ibm.com
      Cc: peterz@infradead.org
      Cc: rostedt@goodmis.org
      Cc: Valdis.Kletnieks@vt.edu
      Cc: dhowells@redhat.com
      LKML-Reference: <12635142581866-git-send-email->
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4c54005c
  32. 16 12月, 2009 1 次提交
  33. 04 12月, 2009 1 次提交