1. 07 10月, 2015 2 次提交
  2. 04 8月, 2015 1 次提交
  3. 03 8月, 2015 1 次提交
  4. 16 7月, 2015 3 次提交
  5. 28 5月, 2015 2 次提交
    • P
      smp: Make control dependencies work on Alpha, improve documentation · 5af4692a
      Paul E. McKenney 提交于
      The current formulation of control dependencies fails on DEC Alpha,
      which does not respect dependencies of any kind unless an explicit
      memory barrier is provided.  This means that the current fomulation of
      control dependencies fails on Alpha.  This commit therefore creates a
      READ_ONCE_CTRL() that has the same overhead on non-Alpha systems, but
      causes Alpha to produce the needed ordering.  This commit also applies
      READ_ONCE_CTRL() to the one known use of control dependencies.
      
      Use of READ_ONCE_CTRL() also has the beneficial effect of adding a bit
      of self-documentation to control dependencies.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      5af4692a
    • W
      documentation: memory-barriers: Fix smp_mb__before_spinlock() semantics · d956028e
      Will Deacon 提交于
      Our current documentation claims that, when followed by an ACQUIRE,
      smp_mb__before_spinlock() orders prior loads against subsequent loads
      and stores, which isn't the intent.  This commit therefore fixes the
      documentation to state that this sequence orders only prior stores
      against subsequent loads and stores.
      
      In addition, the original intent of smp_mb__before_spinlock() was to only
      order prior loads against subsequent stores, however, people have started
      using it as if it ordered prior loads against subsequent loads and stores.
      This commit therefore also updates smp_mb__before_spinlock()'s header
      comment to reflect this new reality.
      
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      d956028e
  6. 19 5月, 2015 1 次提交
  7. 09 4月, 2015 1 次提交
  8. 27 2月, 2015 1 次提交
  9. 08 1月, 2015 2 次提交
  10. 12 12月, 2014 1 次提交
    • A
      arch: Add lightweight memory barriers dma_rmb() and dma_wmb() · 1077fa36
      Alexander Duyck 提交于
      There are a number of situations where the mandatory barriers rmb() and
      wmb() are used to order memory/memory operations in the device drivers
      and those barriers are much heavier than they actually need to be.  For
      example in the case of PowerPC wmb() calls the heavy-weight sync
      instruction when for coherent memory operations all that is really needed
      is an lsync or eieio instruction.
      
      This commit adds a coherent only version of the mandatory memory barriers
      rmb() and wmb().  In most cases this should result in the barrier being the
      same as the SMP barriers for the SMP case, however in some cases we use a
      barrier that is somewhere in between rmb() and smp_rmb().  For example on
      ARM the rmb barriers break down as follows:
      
        Barrier   Call     Explanation
        --------- -------- ----------------------------------
        rmb()     dsb()    Data synchronization barrier - system
        dma_rmb() dmb(osh) data memory barrier - outer sharable
        smp_rmb() dmb(ish) data memory barrier - inner sharable
      
      These new barriers are not as safe as the standard rmb() and wmb().
      Specifically they do not guarantee ordering between coherent and incoherent
      memories.  The primary use case for these would be to enforce ordering of
      reads and writes when accessing coherent memory that is shared between the
      CPU and a device.
      
      It may also be noted that there is no dma_mb().  Most architectures don't
      provide a good mechanism for performing a coherent only full barrier without
      resorting to the same mechanism used in mb().  As such there isn't much to
      be gained in trying to define such a function.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Michael Neuling <mikey@neuling.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: David Miller <davem@davemloft.net>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NAlexander Duyck <alexander.h.duyck@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1077fa36
  11. 14 11月, 2014 2 次提交
  12. 21 10月, 2014 1 次提交
    • W
      documentation: memory-barriers: clarify relaxed io accessor semantics · a8e0aead
      Will Deacon 提交于
      This patch extends the paragraph describing the relaxed read io accessors
      so that the relaxed accessors are defined to be:
      
       - Ordered with respect to each other if accessing the same peripheral
      
       - Unordered with respect to normal memory accesses
      
       - Unordered with respect to LOCK/UNLOCK operations
      
      Whilst many architectures will provide stricter semantics, ARM, Alpha and
      PPC can achieve significant performance gains by taking advantage of some
      or all of the above relaxations.
      
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      a8e0aead
  13. 08 9月, 2014 3 次提交
  14. 08 7月, 2014 2 次提交
  15. 07 6月, 2014 1 次提交
  16. 18 4月, 2014 1 次提交
  17. 21 3月, 2014 1 次提交
  18. 25 2月, 2014 1 次提交
  19. 18 2月, 2014 3 次提交
  20. 12 1月, 2014 1 次提交
  21. 16 12月, 2013 5 次提交
  22. 22 11月, 2013 1 次提交
  23. 20 8月, 2013 1 次提交
  24. 09 1月, 2013 1 次提交
  25. 24 10月, 2012 1 次提交