From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Andrew Morton <akpm@osdl.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
linux-kernel@vger.kernel.org,
"Martin J. Bligh" <mbligh@mbligh.org>,
Christoph Hellwig <hch@infradead.org>,
Douglas Niehaus <niehaus@eecs.ku.edu>,
Ingo Molnar <mingo@redhat.com>,
ltt-dev@shafik.org, systemtap@sources.redhat.com,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [Ltt-dev] [PATCH] local_t : Documentation - update
Date: Tue, 9 Jan 2007 20:06:44 -0500 [thread overview]
Message-ID: <20070110010644.GA8558@Krystal> (raw)
In-Reply-To: <20070110003926.GA27830@Krystal>
* Mathieu Desnoyers (mathieu.desnoyers@polymtl.ca) wrote:
> > So it is "one cpu may write, other cpus may read", and as big as
> > long. Are you sure obscure architectures (sparc?) can implement this
> > in useful way? ... maybe yes, unless obscure architecture exists where
> > second other cpu can see garbage data when first cpu writes into long
> > ...?
> >
> >
>
> Sparc64 uses a memory barrier around the atomic operations in the SMP case
> (see arch/sparc64/lib/atomic.S). The same is true for sparc. As I am not a sparc
> expert, I left the asm-generic default behavior, but I think it should be safe
> to implement local.S code derived from atomic.S to optimize the speed of the
> local_t operations on sparc and sparc64. Can anyone confirm this ?
>
Sorry for the self reply.. looking at arch/sparc/lib/atomic32.c tells me that
local.h could use its own version that would only disable interrupts without
taking any hashed spinlock.
sparc64 seems to be a saner architecture providing atomic operations wrt the
local CPU. A barrier-free version of arch/sparc64/lib/atomic.S would improve
performance.
Mathieu
--
OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
prev parent reply other threads:[~2007-01-10 1:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-21 0:15 [PATCH 0/10] local_t : adding and standardising atomic primitives Mathieu Desnoyers
2006-12-21 0:20 ` [PATCH 1/10] local_t : architecture agnostic Mathieu Desnoyers
2006-12-21 0:21 ` [PATCH 2/10] local_t : alpha Mathieu Desnoyers
2006-12-21 0:22 ` [PATCH 3/10] local_t : i386 Mathieu Desnoyers
2006-12-21 19:44 ` [Ltt-dev] [PATCH 3/10] local_t : i386, local_add_return fix Mathieu Desnoyers
2006-12-21 0:23 ` [PATCH 4/10] local_t : ia64 Mathieu Desnoyers
2006-12-21 0:25 ` [PATCH 5/10] " Mathieu Desnoyers
2006-12-21 14:04 ` [Ltt-dev] [PATCH 5/10] local_t : MIPS Mathieu Desnoyers
2006-12-21 0:25 ` [PATCH 6/10] local_t : parisc Mathieu Desnoyers
2006-12-21 0:27 ` [PATCH 7/10] local_t : powerpc Mathieu Desnoyers
2006-12-21 0:27 ` Mathieu Desnoyers
2006-12-21 3:34 ` [Ltt-dev] " Mathieu Desnoyers
2007-01-24 9:08 ` Paul Mackerras
2007-01-24 9:08 ` Paul Mackerras
2007-01-24 10:43 ` Gabriel Paubert
2007-01-24 10:43 ` Gabriel Paubert
2007-01-24 17:00 ` Mathieu Desnoyers
2007-01-24 17:00 ` Mathieu Desnoyers
2006-12-21 0:27 ` [PATCH 8/10] local_t : s390 Mathieu Desnoyers
2006-12-21 0:28 ` [PATCH 9/10] local_t : sparc64 Mathieu Desnoyers
2006-12-21 0:29 ` [PATCH 10/10] local_t : x86_64 Mathieu Desnoyers
2006-12-21 19:46 ` [Ltt-dev] [PATCH 10/10] local_t : x86_64 : local_add_return Mathieu Desnoyers
2006-12-23 9:33 ` [PATCH 0/10] local_t : adding and standardising atomic primitives Pavel Machek
2007-01-09 3:14 ` [PATCH] local_t : Documentation Mathieu Desnoyers
2007-01-09 21:01 ` Andrew Morton
2007-01-09 22:06 ` Mathieu Desnoyers
2007-01-09 22:11 ` Andrew Morton
2007-01-09 22:38 ` Pavel Machek
2007-01-09 22:41 ` Pavel Machek
2007-01-09 23:21 ` [PATCH] local_t : Documentation - update Mathieu Desnoyers
2007-01-09 23:45 ` Pavel Machek
2007-01-10 0:39 ` Mathieu Desnoyers
2007-01-10 1:06 ` Mathieu Desnoyers [this message]
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=20070110010644.GA8558@Krystal \
--to=compudj@krystal.dyndns.org \
--cc=akpm@osdl.org \
--cc=gregkh@suse.de \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltt-dev@shafik.org \
--cc=mbligh@mbligh.org \
--cc=mingo@redhat.com \
--cc=niehaus@eecs.ku.edu \
--cc=pavel@ucw.cz \
--cc=systemtap@sources.redhat.com \
--cc=tglx@linutronix.de \
/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.