All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andres Lagar-Cavilla <andreslc@gridcentric.ca>
To: xen-devel@lists.xen.org
Cc: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH 6/9] tools: memshr: arm64 support
Date: Fri, 15 Mar 2013 10:30:52 -0400	[thread overview]
Message-ID: <ED2BEB4C-9D2A-4A49-B717-C3C04C8A71D6@gridcentric.ca> (raw)
In-Reply-To: <mailman.26350.1363354644.1399.xen-devel@lists.xen.org>


[-- Attachment #1.1: Type: text/plain, Size: 3691 bytes --]

> I'm not mad keen on propagating these sorts of asm atomic operations throughout
> our code base. Other options would be:

gcc has atomic builtins to do this kind of work. I don't know about arm, but they do the job in x86
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Atomic-Builtins.html
so atomic_inc(val) -> __sync_fetch_and_add(val, 1) and likewise for dec/sub

Andres

> 
> - use libatomic-ops, http://www.hpl.hp.com/research/linux/atomic_ops/, although
>  this doesn't seem to be as widespread as I would like (not in RHEL5 for
>  example)
> - use a pthread lock. This is probably the simplest/best option but I wasn't
>  able to figure out the locking hierarchy of this code
> 
> So I've coped out and just copied the appropriate inlines here.
> 
> I also nuked some stray ia64 support and fixed a coment in the arm32 version
> while I was here.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> tools/memshr/bidir-hash.c |   48 +++++++++++++++++++++++++++++++++-----------
> 1 files changed, 36 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/memshr/bidir-hash.c b/tools/memshr/bidir-hash.c
> index 45d473e..bed8179 100644
> --- a/tools/memshr/bidir-hash.c
> +++ b/tools/memshr/bidir-hash.c
> @@ -100,22 +100,13 @@ int            __hash_iterator(struct __hash *h,
>                         void *d);
> static void      hash_resize(struct __hash *h);
> 
> -#if defined(__ia64__)
> -#define ia64_fetchadd4_rel(p, inc) do {                         \
> -    uint64_t ia64_intri_res;                                    \
> -    asm volatile ("fetchadd4.rel %0=[%1],%2"                    \
> -                : "=r"(ia64_intri_res) : "r"(p), "i" (inc)      \
> -                : "memory");                                    \
> -} while (0)
> -static inline void atomic_inc(uint32_t *v) { ia64_fetchadd4_rel(v, 1); }
> -static inline void atomic_dec(uint32_t *v) { ia64_fetchadd4_rel(v, -1); }
> -#elif defined(__arm__)
> +#if defined(__arm__)
> static inline void atomic_inc(uint32_t *v)
> {
>         unsigned long tmp;
>         int result;
> 
> -        __asm__ __volatile__("@ atomic_add\n"
> +        __asm__ __volatile__("@ atomic_inc\n"
> "1:     ldrex   %0, [%3]\n"
> "       add     %0, %0, #1\n"
> "       strex   %1, %0, [%3]\n"
> @@ -130,7 +121,7 @@ static inline void atomic_dec(uint32_t *v)
>         unsigned long tmp;
>         int result;
> 
> -        __asm__ __volatile__("@ atomic_sub\n"
> +        __asm__ __volatile__("@ atomic_dec\n"
> "1:     ldrex   %0, [%3]\n"
> "       sub     %0, %0, #1\n"
> "       strex   %1, %0, [%3]\n"
> @@ -140,6 +131,39 @@ static inline void atomic_dec(uint32_t *v)
>         : "r" (v)
>         : "cc");
> }
> +
> +#elif defined(__aarch64__)
> +
> +static inline void atomic_inc(uint32_t *v)
> +{
> +        unsigned long tmp;
> +        int result;
> +
> +        asm volatile("// atomic_inc\n"
> +"1:     ldxr    %w0, [%3]\n"
> +"       add     %w0, %w0, #1\n"
> +"       stxr    %w1, %w0, [%3]\n"
> +"       cbnz    %w1, 1b"
> +        : "=&r" (result), "=&r" (tmp), "+o" (v)
> +        : "r" (v)
> +        : "cc");
> +}
> +
> +static inline void atomic_dec(uint32_t *v)
> +{
> +        unsigned long tmp;
> +        int result;
> +
> +        asm volatile("// atomic_dec\n"
> +"1:     ldxr    %w0, [%3]\n"
> +"       sub     %w0, %w0, #1\n"
> +"       stxr    %w1, %w0, [%3]\n"
> +"       cbnz    %w1, 1b"
> +        : "=&r" (result), "=&r" (tmp), "+o" (v)
> +        : "r" (v)
> +        : "cc");
> +}
> +
> #else /* __x86__ */
> static inline void atomic_inc(uint32_t *v)
> {
> -- 
> 1.7.2.5


[-- Attachment #1.2: Type: text/html, Size: 6669 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

       reply	other threads:[~2013-03-15 14:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.26350.1363354644.1399.xen-devel@lists.xen.org>
2013-03-15 14:30 ` Andres Lagar-Cavilla [this message]
2013-03-15 14:35   ` [PATCH 6/9] tools: memshr: arm64 support Ian Campbell
2013-03-15 13:15 [PATCH 00/09] arm: tools: build for arm64 and enable cross-compiling for both arm32 and arm64 Ian Campbell
2013-03-15 13:15 ` [PATCH 6/9] tools: memshr: arm64 support Ian Campbell
2013-03-15 15:29   ` Ian Jackson
2013-03-19 15:52   ` Stefano Stabellini

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=ED2BEB4C-9D2A-4A49-B717-C3C04C8A71D6@gridcentric.ca \
    --to=andreslc@gridcentric.ca \
    --cc=ian.campbell@citrix.com \
    --cc=xen-devel@lists.xen.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.