From: David Howells <dhowells@redhat.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: dhowells@redhat.com, Ingo Molnar <mingo@elte.hu>,
Paul Mackerras <paulus@samba.org>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
David Miller <davem@davemloft.net>,
Paul Mundt <lethal@linux-sh.org>,
Will Deacon <will.deacon@arm.com>,
Deng-Cheng Zhu <dengcheng.zhu@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-arch@vger.kernel.org
Subject: Re: [PATCH 1/4] arch: local64_t
Date: Fri, 21 May 2010 15:52:29 +0100 [thread overview]
Message-ID: <23895.1274453549@redhat.com> (raw)
In-Reply-To: <20100521135944.884367426@chello.nl>
Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> + * This is the default implementation, which uses atomic64_t. Which is
> + * rather pointless. The whole point behind local64_t is that some processors
> + * can perform atomic adds and subtracts in a manner which is atomic wrt IRQs
> + * running on this CPU. local64_t allows exploitation of such capabilities.
Interesting... What FRV does in atomic64-ops.S should probably be rebranded
local64_t, and atomic64_t ops be based on that in non-SMP mode.
What I did on FRV was to emulate LL/ST instructions using some of the
excessive numbers of conditional bits to do so - but it only works on UP
systems.
David
next prev parent reply other threads:[~2010-05-21 14:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-21 13:42 [PATCH 0/4] convert perf to local64_t Peter Zijlstra
2010-05-21 13:42 ` [PATCH 1/4] arch: local64_t Peter Zijlstra
2010-05-21 14:47 ` Kyle McMartin
2010-05-21 14:52 ` David Howells [this message]
2010-05-21 13:42 ` [PATCH 2/4] perf: Add perf_event_count() Peter Zijlstra
2010-05-21 13:42 ` [PATCH 3/4] perf: Add child_count Peter Zijlstra
2010-05-21 13:42 ` [PATCH 4/4] perf: Convert perf_event to local_t Peter Zijlstra
2010-05-26 10:08 ` [PATCH 0/4] convert perf to local64_t Frederic Weisbecker
2010-05-26 10:11 ` Peter Zijlstra
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=23895.1274453549@redhat.com \
--to=dhowells@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=davem@davemloft.net \
--cc=dengcheng.zhu@gmail.com \
--cc=fweisbec@gmail.com \
--cc=lethal@linux-sh.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=will.deacon@arm.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.