From: "Steve Wise" <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
To: 'Jason Gunthorpe'
<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: RE: [PATCH RFC] libibverbs: add ARM64 memory barrier macros
Date: Thu, 19 May 2016 11:35:41 -0500 [thread overview]
Message-ID: <060c01d1b1ec$7b9e5fb0$72db1f10$@opengridcomputing.com> (raw)
In-Reply-To: <060701d1b1e7$dc7e1ff0$957a5fd0$@opengridcomputing.com>
> > These days, in user space this sort of stuff should be done following
> > the C11 atomic memory ordering model and not by trying to shoe-horn in
> > the kernel model. Then the compiler takes care of things properly.
> >
> > This is using calls like atomic_store, atomic_load and
> > atomic_thread_fence to create the same sort of barriers.
> >
> > You could probably implement the Xmbs() with variations on
> > atomic_thread_fence ??
>
> Looking at the documentation, it is not clear to me which parameter value
passed
> to atomic_thread_fence() maps to each of the mb services. Is it correct to
> think that if I get it right, the resulting assembly should be what we
currently
> have for the mb services?
>
> Or perhaps someone else can provide guidance?
>
I created a simple program to call __atomic_thread_fence() with the various
parameters, using the x64 architecture. Only __ATOMIC_SEQ_CST seems to add any
code (mfence) when the binary is inspected with 'objdump -lS'. The rest are
no-ops. I'm not sure this will work for libibeverbs.
Here is the program, compiled with -g -O0:
-----
[root@stevo3 ~]# cc -g -O0 atomic_thread_fence.c -o atomic_thread_fence
[root@stevo3 ~]# cat atomic_thread_fence.c
#include <stdio.h>
#define mb() __atomic_thread_fence(__ATOMIC_SEQ_CST)
int main(int argc, char *argv[])
{
int a;
a = 1;
printf("ATOMIC_RELAXED\n");
__atomic_thread_fence(__ATOMIC_RELAXED);
a = 2;
printf("ATOMIC_CONSUME\n");
__atomic_thread_fence(__ATOMIC_CONSUME);
a = 3;
printf("ATOMIC_RELEASE\n");
__atomic_thread_fence(__ATOMIC_RELEASE);
a = 4;
printf("ATOMIC_ACQ_REL\n");
__atomic_thread_fence(__ATOMIC_ACQ_REL);
a = 5;
printf("ATOMIC_SEQ_CST\n");
__atomic_thread_fence(__ATOMIC_SEQ_CST);
printf("a=%d\n", a);
}
-----
Here is the objdump snipit:
-----
int main(int argc, char *argv[])
{
400580: 55 push %rbp
400581: 48 89 e5 mov %rsp,%rbp
400584: 48 83 ec 20 sub $0x20,%rsp
400588: 89 7d ec mov %edi,-0x14(%rbp)
40058b: 48 89 75 e0 mov %rsi,-0x20(%rbp)
/root/atomic_thread_fence.c:9
int a;
a = 1;
40058f: c7 45 fc 01 00 00 00 movl $0x1,-0x4(%rbp)
/root/atomic_thread_fence.c:10
printf("ATOMIC_RELAXED\n");
400596: bf 90 06 40 00 mov $0x400690,%edi
40059b: e8 b0 fe ff ff callq 400450 <puts@plt>
/root/atomic_thread_fence.c:12
__atomic_thread_fence(__ATOMIC_RELAXED);
a = 2;
4005a0: c7 45 fc 02 00 00 00 movl $0x2,-0x4(%rbp)
/root/atomic_thread_fence.c:13
printf("ATOMIC_CONSUME\n");
4005a7: bf 9f 06 40 00 mov $0x40069f,%edi
4005ac: e8 9f fe ff ff callq 400450 <puts@plt>
/root/atomic_thread_fence.c:15
__atomic_thread_fence(__ATOMIC_CONSUME);
a = 3;
4005b1: c7 45 fc 03 00 00 00 movl $0x3,-0x4(%rbp)
/root/atomic_thread_fence.c:16
printf("ATOMIC_RELEASE\n");
4005b8: bf ae 06 40 00 mov $0x4006ae,%edi
4005bd: e8 8e fe ff ff callq 400450 <puts@plt>
/root/atomic_thread_fence.c:18
__atomic_thread_fence(__ATOMIC_RELEASE);
a = 4;
4005c2: c7 45 fc 04 00 00 00 movl $0x4,-0x4(%rbp)
/root/atomic_thread_fence.c:19
printf("ATOMIC_ACQ_REL\n");
4005c9: bf bd 06 40 00 mov $0x4006bd,%edi
4005ce: e8 7d fe ff ff callq 400450 <puts@plt>
/root/atomic_thread_fence.c:21
__atomic_thread_fence(__ATOMIC_ACQ_REL);
a = 5;
4005d3: c7 45 fc 05 00 00 00 movl $0x5,-0x4(%rbp)
/root/atomic_thread_fence.c:22
printf("ATOMIC_SEQ_CST\n");
4005da: bf cc 06 40 00 mov $0x4006cc,%edi
4005df: e8 6c fe ff ff callq 400450 <puts@plt>
/root/atomic_thread_fence.c:23
__atomic_thread_fence(__ATOMIC_SEQ_CST);
4005e4: 0f ae f0 mfence
/root/atomic_thread_fence.c:24
printf("a=%d\n", a);
4005e7: 8b 45 fc mov -0x4(%rbp),%eax
4005ea: 89 c6 mov %eax,%esi
4005ec: bf db 06 40 00 mov $0x4006db,%edi
4005f1: b8 00 00 00 00 mov $0x0,%eax
4005f6: e8 65 fe ff ff callq 400460 <printf@plt>
/root/atomic_thread_fence.c:25
}
4005fb: c9 leaveq
4005fc: c3 retq
4005fd: 0f 1f 00 nopl (%rax)
-----
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-05-19 16:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-18 21:16 [PATCH RFC] libibverbs: add ARM64 memory barrier macros Steve Wise
[not found] ` <20160518220302.81260E09E9-/5N3P9jjx0xzbRFIqnYvSA@public.gmane.org>
2016-05-18 22:28 ` Jason Gunthorpe
[not found] ` <20160518222857.GB23835-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-05-19 16:02 ` Steve Wise
2016-05-19 16:35 ` Steve Wise [this message]
2016-05-19 18:05 ` Jason Gunthorpe
[not found] ` <20160519180552.GA26130-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-05-19 18:54 ` Steve Wise
2016-05-19 19:28 ` Jason Gunthorpe
[not found] ` <20160519192805.GA32668-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
2016-05-20 9:44 ` Gabriele Svelto
[not found] ` <b4eb5c63-9f20-b927-ebc8-f8016accc93c-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-05-24 17:22 ` Jason Gunthorpe
2016-05-19 20:14 ` Bart Van Assche
[not found] ` <573E1EC3.5000907-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
2016-05-19 20:57 ` Jason Gunthorpe
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='060c01d1b1ec$7b9e5fb0$72db1f10$@opengridcomputing.com' \
--to=swise-7bpotxp6k4+p2yhjcf5u+vpxobypeauw@public.gmane.org \
--cc=dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.