1. 16 7月, 2014 1 次提交
    • J
      locking/spinlocks/mcs: Rename optimistic_spin_queue() to optimistic_spin_node() · 046a619d
      Jason Low 提交于
      Currently, the per-cpu nodes structure for the cancellable MCS spinlock is
      named "optimistic_spin_queue". However, in a follow up patch in the series
      we will be introducing a new structure that serves as the new "handle" for
      the lock. It would make more sense if that structure is named
      "optimistic_spin_queue". Additionally, since the current use of the
      "optimistic_spin_queue" structure are  "nodes", it might be better if we
      rename them to "node" anyway.
      
      This preparatory patch renames all current "optimistic_spin_queue"
      to "optimistic_spin_node".
      Signed-off-by: NJason Low <jason.low2@hp.com>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Scott Norton <scott.norton@hp.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Dave Chinner <david@fromorbit.com>
      Cc: Waiman Long <waiman.long@hp.com>
      Cc: Davidlohr Bueso <davidlohr@hp.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Aswin Chandramouleeswaran <aswin@hp.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Chris Mason <clm@fb.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Josef Bacik <jbacik@fusionio.com>
      Link: http://lkml.kernel.org/r/1405358872-3732-2-git-send-email-jason.low2@hp.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      046a619d
  2. 05 6月, 2014 2 次提交
    • D
      locking/rwsem: Fix warnings for CONFIG_RWSEM_GENERIC_SPINLOCK · dbb5eafa
      Davidlohr Bueso 提交于
      Optimistic spinning is only used by the xadd variant
      of rw-semaphores. Make sure that we use the old version
      of the __RWSEM_INITIALIZER macro for systems that rely
      on the spinlock one, otherwise warnings can be triggered,
      such as the following reported on an arm box:
      
        ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer [enabled by default]
        ipc/ipcns_notifier.c:22:8: warning: (near initialization for 'ipcns_chain.rwsem') [enabled by default]
        ipc/ipcns_notifier.c:22:8: warning: excess elements in struct initializer [enabled by default]
        ipc/ipcns_notifier.c:22:8: warning: (near initialization for 'ipcns_chain.rwsem') [enabled by default]
      Signed-off-by: NDavidlohr Bueso <davidlohr@hp.com>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: Alex Shi <alex.shi@linaro.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Jason Low <jason.low2@hp.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Chris Mason <clm@fb.com>
      Cc: Josef Bacik <jbacik@fusionio.com>
      Link: http://lkml.kernel.org/r/1400545677.6399.10.camel@buesod1.americas.hpqcorp.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      dbb5eafa
    • D
      locking/rwsem: Support optimistic spinning · 4fc828e2
      Davidlohr Bueso 提交于
      We have reached the point where our mutexes are quite fine tuned
      for a number of situations. This includes the use of heuristics
      and optimistic spinning, based on MCS locking techniques.
      
      Exclusive ownership of read-write semaphores are, conceptually,
      just about the same as mutexes, making them close cousins. To
      this end we need to make them both perform similarly, and
      right now, rwsems are simply not up to it. This was discovered
      by both reverting commit 4fc3f1d6 (mm/rmap, migration: Make
      rmap_walk_anon() and try_to_unmap_anon() more scalable) and
      similarly, converting some other mutexes (ie: i_mmap_mutex) to
      rwsems. This creates a situation where users have to choose
      between a rwsem and mutex taking into account this important
      performance difference. Specifically, biggest difference between
      both locks is when we fail to acquire a mutex in the fastpath,
      optimistic spinning comes in to play and we can avoid a large
      amount of unnecessary sleeping and overhead of moving tasks in
      and out of wait queue. Rwsems do not have such logic.
      
      This patch, based on the work from Tim Chen and I, adds support
      for write-side optimistic spinning when the lock is contended.
      It also includes support for the recently added cancelable MCS
      locking for adaptive spinning. Note that is is only applicable
      to the xadd method, and the spinlock rwsem variant remains intact.
      
      Allowing optimistic spinning before putting the writer on the wait
      queue reduces wait queue contention and provided greater chance
      for the rwsem to get acquired. With these changes, rwsem is on par
      with mutex. The performance benefits can be seen on a number of
      workloads. For instance, on a 8 socket, 80 core 64bit Westmere box,
      aim7 shows the following improvements in throughput:
      
       +--------------+---------------------+-----------------+
       |   Workload   | throughput-increase | number of users |
       +--------------+---------------------+-----------------+
       | alltests     | 20%                 | >1000           |
       | custom       | 27%, 60%            | 10-100, >1000   |
       | high_systime | 36%, 30%            | >100, >1000     |
       | shared       | 58%, 29%            | 10-100, >1000   |
       +--------------+---------------------+-----------------+
      
      There was also improvement on smaller systems, such as a quad-core
      x86-64 laptop running a 30Gb PostgreSQL (pgbench) workload for up
      to +60% in throughput for over 50 clients. Additionally, benefits
      were also noticed in exim (mail server) workloads. Furthermore, no
      performance regression have been seen at all.
      
      Based-on-work-from: Tim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: NDavidlohr Bueso <davidlohr@hp.com>
      [peterz: rej fixup due to comment patches, sched/rt.h header]
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Alex Shi <alex.shi@linaro.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Michel Lespinasse <walken@google.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Peter Hurley <peter@hurleysoftware.com>
      Cc: "Paul E.McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Jason Low <jason.low2@hp.com>
      Cc: Aswin Chandramouleeswaran <aswin@hp.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: "Scott J Norton" <scott.norton@hp.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Chris Mason <clm@fb.com>
      Cc: Josef Bacik <jbacik@fusionio.com>
      Link: http://lkml.kernel.org/r/1399055055.6275.15.camel@buesod1.americas.hpqcorp.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      4fc828e2
  3. 29 1月, 2014 1 次提交
  4. 24 3月, 2013 1 次提交
  5. 17 1月, 2013 1 次提交
  6. 12 1月, 2013 1 次提交
  7. 29 3月, 2012 1 次提交
  8. 13 9月, 2011 1 次提交
  9. 27 7月, 2011 1 次提交
  10. 21 7月, 2011 1 次提交
  11. 27 1月, 2011 6 次提交
  12. 30 4月, 2008 1 次提交
  13. 11 7月, 2006 1 次提交
  14. 04 7月, 2006 2 次提交
  15. 26 4月, 2006 1 次提交
  16. 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