All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: David Miller <davem@davemloft.net>
Cc: paulmck@linux.vnet.ibm.com, mingo@elte.hu,
	jwboyer@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
	ltt-dev@lists.casi.polymtl.ca
Subject: Re: cli/sti vs local_cmpxchg and local_add_return
Date: Tue, 17 Mar 2009 00:44:54 -0400	[thread overview]
Message-ID: <20090317044454.GA28245@Krystal> (raw)
In-Reply-To: <20090316.212717.233062381.davem@davemloft.net>

* David Miller (davem@davemloft.net) wrote:
> From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> Date: Tue, 17 Mar 2009 00:10:16 -0400
> 
> > Thanks for running those tests. Actually, I did not expect good results
> > for sparc64 because the local_t primitives map to atomic_t. Looking at
> > sparc atomic_64.h, I notice that all atomic operations except cmpxchg
> > are done through function calls even when those functions only contain
> > few instructions.  Is there any particular reason for that ? These
> > function calls can be quite costly. We could easily inline those.
> 
> With all the memory barriers, cpu bug workarounds, et al.
> it's way too much to expand inline.
> 
> > And to "unleash" the full power of local_t, we should see if there are
> > variants of the atomic operations which are safe only on UP and if there
> > are some memory barriers currently embedded in the atomic_t ops we could
> > remove in a local_t version. Actually, all the
> > BACKOFF_SETUP/BACKOFF_SPIN is specific to SMP, and therefore the local_t
> > version probably does not need that because it touches specifically
> > per-cpu data. That could give very interesting results.
> > 
> > The reason why the results shows 0 cycles per loop is just because there
> > is less that a bus clock cycle per loop. But the total time (in bus
> > cycles) for the whole 20000 cycles gives us equivalent information.
> 
> I don't think it's worth it.  Rusty made similar tests not too long
> ago.
> 
> IRQ disabling/enabling on sparc64 is 9 cycles (each) and the atomic
> operation on the other hand is at least 35 cycles.

OK, so sparc64 should probably implement local_t with interrupt
disabling on the local CPU and two atomic aligned operations (1 read, 1
write) of 64-bits variables from/to memory, so we make sure that if a
remote CPU tries to simply read the information, it is never seen as
corrupted.

Note that any code doing "remote reads" and "write expected to be read
from a remote cpu" on local_t variables must provide its own memory
barriers.

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2009-03-17  4:45 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-17  1:32 cli/sti vs local_cmpxchg and local_add_return Mathieu Desnoyers
2009-03-17  3:37 ` David Miller
2009-03-17  4:10   ` Mathieu Desnoyers
2009-03-17  4:27     ` David Miller
2009-03-17  4:44       ` Mathieu Desnoyers [this message]
2009-03-17  5:01 ` Paul E. McKenney
2009-03-17 16:06   ` Mathieu Desnoyers
2009-03-17 19:28     ` David Miller
2009-03-17 19:35       ` Mathieu Desnoyers
2009-03-17  6:05 ` Nick Piggin
2009-03-17 15:14   ` [ltt-dev] " Mathieu Desnoyers
2009-03-18 11:43     ` Nick Piggin
2009-03-18 15:10       ` Mathieu Desnoyers
2009-03-17 18:42 ` Alan D. Brunelle
2009-03-17 19:01   ` Andika Triwidada
2009-03-23 16:50   ` Mathieu Desnoyers
2009-03-18 11:56 ` Josh Boyer
2009-03-23 16:56   ` Mathieu Desnoyers
2009-03-23 17:04     ` Josh Boyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090317044454.GA28245@Krystal \
    --to=mathieu.desnoyers@polymtl.ca \
    --cc=davem@davemloft.net \
    --cc=jwboyer@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@lists.casi.polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.