On Thu, Oct 31, 2013 at 03:57:14PM +0200, Michael S. Tsirkin wrote:
On Wed, Oct 30, 2013 at 09:56:29PM -0700, Paul E. McKenney wrote:
On Thu, Oct 31, 2013 at 01:26:05AM +0200, Michael S. Tsirkin wrote:
Paul, could you review this patch please?
Documentation/memory-barriers.txt says
On Wed, Oct 30, 2013 at 09:56:29PM -0700, Paul E. McKenney wrote:
On Thu, Oct 31, 2013 at 01:26:05AM +0200, Michael S. Tsirkin wrote:
Paul, could you review this patch please?
Documentation/memory-barriers.txt says that unlock has a weaker
uni-directional barrier, but in practice
Il 31/10/2013 07:47, Gleb Natapov ha scritto:
This looks dubious to me. All other smp_mb__after_* variants are there
because some atomic operations have different memory barrier semantics on
different arches,
It doesn't have to be arches; unlock APIs typically have release
semantics only, but
Il 30/10/2013 20:09, Michael S. Tsirkin ha scritto:
I noticed that srcu_read_lock/unlock both have a memory barrier,
so just by moving srcu_read_unlock earlier we can get rid of
one call to smp_mb().
Unsurprisingly, the gain is small but measureable using the unit test
microbenchmark:
On Thu, Oct 31, 2013 at 12:14:15PM +0100, Paolo Bonzini wrote:
Il 30/10/2013 20:09, Michael S. Tsirkin ha scritto:
I noticed that srcu_read_lock/unlock both have a memory barrier,
so just by moving srcu_read_unlock earlier we can get rid of
one call to smp_mb().
Unsurprisingly, the
On Thu, Oct 31, 2013 at 12:11:21PM +0100, Paolo Bonzini wrote:
Il 31/10/2013 07:47, Gleb Natapov ha scritto:
This looks dubious to me. All other smp_mb__after_* variants are there
because some atomic operations have different memory barrier semantics on
different arches,
It doesn't have
On Wed, Oct 30, 2013 at 09:56:29PM -0700, Paul E. McKenney wrote:
On Thu, Oct 31, 2013 at 01:26:05AM +0200, Michael S. Tsirkin wrote:
Paul, could you review this patch please?
Documentation/memory-barriers.txt says that unlock has a weaker
uni-directional barrier, but in practice
I noticed that srcu_read_lock/unlock both have a memory barrier,
so just by moving srcu_read_unlock earlier we can get rid of
one call to smp_mb().
Unsurprisingly, the gain is small but measureable using the unit test
microbenchmark:
before
vmcall 1407
after
vmcall 1357
On Wed, Oct 30, 2013 at 09:09:29PM +0200, Michael S. Tsirkin wrote:
I noticed that srcu_read_lock/unlock both have a memory barrier,
so just by moving srcu_read_unlock earlier we can get rid of
one call to smp_mb().
Unsurprisingly, the gain is small but measureable using the unit test
Paul, could you review this patch please?
Documentation/memory-barriers.txt says that unlock has a weaker
uni-directional barrier, but in practice srcu_read_unlock calls
smp_mb().
Is it OK to rely on this? If not, can I add
smp_mb__after_srcu_read_unlock (making it an empty macro
On Thu, Oct 31, 2013 at 01:26:05AM +0200, Michael S. Tsirkin wrote:
Paul, could you review this patch please?
Documentation/memory-barriers.txt says that unlock has a weaker
uni-directional barrier, but in practice srcu_read_unlock calls
smp_mb().
Is it OK to rely on this? If
11 matches
Mail list logo
