From: David Daney <ddaney@caviumnetworks.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Deng-Cheng Zhu <dengcheng.zhu@gmail.com>,
linux-mips@linux-mips.org, a.p.zijlstra@chello.nl,
paulus@samba.org, mingo@elte.hu, acme@redhat.com,
jamie.iles@picochip.com
Subject: Re: [PATCH 1/3] MIPS: use the generic atomic64 operations for perf counter support
Date: Wed, 21 Apr 2010 10:45:11 -0700 [thread overview]
Message-ID: <4BCF39A7.3020708@caviumnetworks.com> (raw)
In-Reply-To: <20100421171915.GA29010@linux-mips.org>
On 04/21/2010 10:19 AM, Ralf Baechle wrote:
[...]
>
> -#ifdef CONFIG_64BIT
> +typedef struct {
> + long long counter;
> +} atomic64_t;
>
How does this not conflict with the definition in linux/types.h for a
64-bit kernel?
> #define ATOMIC64_INIT(i) { (i) }
>
> @@ -410,14 +414,44 @@ static __inline__ int atomic_add_unless(atomic_t *v, int a, int u)
> * @v: pointer of type atomic64_t
> *
> */
> -#define atomic64_read(v) ((v)->counter)
> +static long long __inline__ atomic64_read(const atomic64_t *v)
> +{
> + unsigned long flags;
> + raw_spinlock_t *lock;
> + long long val;
> +
> + if (cpu_has_64bit_gp_regs) /* 64-bit regs imply 64-bit ld / sd */
> + return v->counter;
> +
How is this atomic for the o32 ABI? counter is now not volatile, in
o32, u64 values are often split between two registers. There is nothing
to guarantee that the compiler will use LD.
David Daney
prev parent reply other threads:[~2010-04-21 17:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-15 16:38 [PATCH 1/3] MIPS: use the generic atomic64 operations for perf counter support Deng-Cheng Zhu
2010-04-20 16:25 ` David Daney
2010-04-21 17:19 ` Ralf Baechle
2010-04-21 17:45 ` David Daney [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=4BCF39A7.3020708@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=dengcheng.zhu@gmail.com \
--cc=jamie.iles@picochip.com \
--cc=linux-mips@linux-mips.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=ralf@linux-mips.org \
/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.