1. 15 5月, 2014 8 次提交
  2. 14 5月, 2014 1 次提交
  3. 24 2月, 2014 22 次提交
  4. 23 2月, 2014 1 次提交
  5. 18 2月, 2014 2 次提交
  6. 13 12月, 2013 1 次提交
    • C
      rcu/torture: Dynamically allocate SRCU output buffer to avoid overflow · d1008950
      Chen Gang 提交于
      If the rcutorture SRCU output exceeds 4096 bytes, for example, if you
      have more than about 75 CPUs, it will overflow the current statically
      allocated buffer.  This commit therefore replaces this static buffer
      with a dynamically buffer whose size is based on the number of CPUs.
      
      Benefits:
      
       - Avoids both buffer overflow and output truncation.
       - Handles an arbitrarily large number of CPUs.
       - Straightforward implementation.
      
      Shortcomings:
      
       - Some memory is wasted:
      
         1 cpu now comsumes 50 - 60 bytes, and this patch provides 200 bytes.
         Therefore, for 1K CPUs, roughly 100KB of memory will be wasted.
         However, the memory is freed immediately after printing, so this
         wastage should not be a problem in practice.
      
      Testing (Fedora16 2 CPUs, 2GB RAM x86_64):
      
       - as module, with/without "torture_type=srcu".
       - build-in not boot runnable, with/without "torture_type=srcu".
       - build-in let boot runnable, with/without "torture_type=srcu".
      Signed-off-by: NChen Gang <gang.chen@asianux.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      d1008950
  7. 04 12月, 2013 1 次提交
    • P
      rcu: Fix and comment ordering around wait_event() · 78e4bc34
      Paul E. McKenney 提交于
      It is all too easy to forget that wait_event() does not necessarily
      imply a full memory barrier.  The case where it does not is where the
      condition transitions to true just as wait_event() starts execution.
      This is actually a feature: The standard use of wait_event() involves
      locking, in which case the locks provide the needed ordering (you hold a
      lock across the wake_up() and acquire that same lock after wait_event()
      returns).
      
      Given that I did forget that wait_event() does not necessarily imply a
      full memory barrier in one case, this commit fixes that case.  This commit
      also adds comments calling out the placement of existing memory barriers
      relied on by wait_event() calls.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      78e4bc34
  8. 16 10月, 2013 1 次提交
  9. 21 8月, 2013 3 次提交