1. 20 Jun, 2011 1 commit
    • Marcin Slusarz's avatar
      debugobjects: Fix boot crash when kmemleak and debugobjects enabled · 161b6ae0
      Marcin Slusarz authored
      Order of initialization look like this:
      ...(lots of other subsystems)...
      workqueues (through early initcall)
      debugobjects use schedule_work for batch freeing of its data and kmemleak
      heavily use debugobjects, so when it comes to freeing and workqueues were
      not initialized yet, kernel crashes:
      BUG: unable to handle kernel NULL pointer dereference at           (null)
      IP: [<ffffffff810854d1>] __queue_work+0x29/0x41a
       [<ffffffff81085910>] queue_work_on+0x16/0x1d
       [<ffffffff81085abc>] queue_work+0x29/0x55
       [<ffffffff81085afb>] schedule_work+0x13/0x15
       [<ffffffff81242de1>] free_object+0x90/0x95
       [<ffffffff81242f6d>] debug_check_no_obj_freed+0x187/0x1d3
       [<ffffffff814b6504>] ? _raw_spin_unlock_irqrestore+0x30/0x4d
       [<ffffffff8110bd14>] ? free_object_rcu+0x68/0x6d
       [<ffffffff8110890c>] kmem_cache_free+0x64/0x12c
       [<ffffffff8110bd14>] free_object_rcu+0x68/0x6d
       [<ffffffff810b58bc>] __rcu_process_callbacks+0x1b6/0x2d9
      because system_wq is NULL.
      Fix it by checking if workqueues susbystem was initialized before using.
      Signed-off-by: default avatarMarcin Slusarz <marcin.slusarz@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: stable@kernel.org
      Link: http://lkml.kernel.org/r/20110528112342.GA3068@joi.lan
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  2. 16 Jun, 2011 2 commits
  3. 14 Jun, 2011 2 commits
    • Shaohua Li's avatar
      rcu: Use softirq to address performance regression · 09223371
      Shaohua Li authored
      Commit a26ac245
      (rcu: move TREE_RCU from softirq to kthread)
      introduced performance regression. In an AIM7 test, this commit degraded
      performance by about 40%.
      The commit runs rcu callbacks in a kthread instead of softirq. We observed
      high rate of context switch which is caused by this. Out test system has
      64 CPUs and HZ is 1000, so we saw more than 64k context switch per second
      which is caused by RCU's per-CPU kthread.  A trace showed that most of
      the time the RCU per-CPU kthread doesn't actually handle any callbacks,
      but instead just does a very small amount of work handling grace periods.
      This means that RCU's per-CPU kthreads are making the scheduler do quite
      a bit of work in order to allow a very small amount of RCU-related
      processing to be done.
      Alex Shi's analysis determined that this slowdown is due to lock
      contention within the scheduler.  Unfortunately, as Peter Zijlstra points
      out, the scheduler's real-time semantics require global action, which
      means that this contention is inherent in real-time scheduling.  (Yes,
      perhaps someone will come up with a workaround -- otherwise, -rt is not
      going to do well on large SMP systems -- but this patch will work around
      this issue in the meantime.  And "the meantime" might well be forever.)
      This patch therefore re-introduces softirq processing to RCU, but only
      for core RCU work.  RCU callbacks are still executed in kthread context,
      so that only a small amount of RCU work runs in softirq context in the
      common case.  This should minimize ksoftirqd execution, allowing us to
      skip boosting of ksoftirqd for CONFIG_RCU_BOOST=y kernels.
      Signed-off-by: default avatarShaohua Li <shaohua.li@intel.com>
      Tested-by: default avatar"Alex,Shi" <alex.shi@intel.com>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
    • Paul E. McKenney's avatar
      rcu: Simplify curing of load woes · 9a432736
      Paul E. McKenney authored
      Make the functions creating the kthreads wake them up.  Leverage the
      fact that the per-node and boost kthreads can run anywhere, thus
      dispensing with the need to wake them up once the incoming CPU has
      gone fully online.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Tested-by: default avatarDaniel J Blueman <daniel.blueman@gmail.com>
  4. 06 Jun, 2011 5 commits
  5. 04 Jun, 2011 17 commits
  6. 03 Jun, 2011 13 commits