1. 23 3月, 2006 1 次提交
  2. 21 3月, 2006 1 次提交
  3. 09 3月, 2006 1 次提交
    • D
      [PATCH] rcu batch tuning · 21a1ea9e
      Dipankar Sarma 提交于
      This patch adds new tunables for RCU queue and finished batches.  There are
      two types of controls - number of completed RCU updates invoked in a batch
      (blimit) and monitoring for high rate of incoming RCUs on a cpu (qhimark,
      qlowmark).
      
      By default, the per-cpu batch limit is set to a small value.  If the input
      RCU rate exceeds the high watermark, we do two things - force quiescent
      state on all cpus and set the batch limit of the CPU to INTMAX.  Setting
      batch limit to INTMAX forces all finished RCUs to be processed in one shot.
       If we have more than INTMAX RCUs queued up, then we have bigger problems
      anyway.  Once the incoming queued RCUs fall below the low watermark, the
      batch limit is set to the default.
      Signed-off-by: NDipankar Sarma <dipankar@in.ibm.com>
      Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      21a1ea9e
  4. 11 1月, 2006 2 次提交
  5. 10 1月, 2006 2 次提交
  6. 09 1月, 2006 3 次提交
  7. 13 12月, 2005 2 次提交
    • S
      [PATCH] Fix RCU race in access of nohz_cpu_mask · c3f59023
      Srivatsa Vaddagiri 提交于
      Accessing nohz_cpu_mask before incrementing rcp->cur is racy.  It can cause
      tickless idle CPUs to be included in rsp->cpumask, which will extend
      graceperiods unnecessarily.
      
      Fix this race.  It has been tested using extensions to RCU torture module
      that forces various CPUs to become idle.
      Signed-off-by: NSrivatsa Vaddagiri <vatsa@in.ibm.com>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c3f59023
    • D
      [PATCH] add rcu_barrier() synchronization point · ab4720ec
      Dipankar Sarma 提交于
      This introduces a new interface - rcu_barrier() which waits until all
      the RCUs queued until this call have been completed.
      
      Reiser4 needs this, because we do more than just freeing memory object
      in our RCU callback: we also remove it from the list hanging off
      super-block.  This means, that before freeing reiser4-specific portion
      of super-block (during umount) we have to wait until all pending RCU
      callbacks are executed.
      
      The only change of reiser4 made to the original patch, is exporting of
      rcu_barrier().
      
      Cc: Hans Reiser <reiser@namesys.com>
      Cc: Vladimir V. Saveliev <vs@namesys.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      ab4720ec
  8. 31 10月, 2005 1 次提交
  9. 18 10月, 2005 2 次提交
    • E
      [PATCH] rcu: keep rcu callback event counter · 5ee832db
      Eric Dumazet 提交于
      This makes call_rcu() keep track of how many events there are on the RCU
      list, and cause a reschedule event when the list gets too long.
      
      This helps keep RCU event lists down.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5ee832db
    • L
      Increase default RCU batching sharply · 2cc78eb5
      Linus Torvalds 提交于
      Dipankar made RCU limit the batch size to improve latency, but that
      approach is unworkable: it can cause the RCU queues to grow without
      bounds, since the batch limiter ended up limiting the callbacks.
      
      So make the limit much higher, and start planning on instead limiting
      the batch size by doing RCU callbacks more often if the queue looks like
      it might be growing too long.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2cc78eb5
  10. 10 9月, 2005 1 次提交
  11. 01 5月, 2005 2 次提交
  12. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4