Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1682875
| From | Boqun Feng <boqun.feng@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 2/9] RISC-V: Atomic and Locking Code |
| Date | 2017-07-07 04:20 +0200 |
| Message-ID | <u0r29-5GR-1@gated-at.bofh.it> (permalink) |
| References | <tZOat-3Wl-9@gated-at.bofh.it> <u0pWq-4VQ-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
On Thu, Jul 06, 2017 at 06:04:13PM -0700, Palmer Dabbelt wrote:
[...]
> >> +#define __smp_load_acquire(p) \
> >> +do { \
> >> + union { typeof(*p) __val; char __c[1]; } __u = \
> >> + { .__val = (__force typeof(*p)) (v) }; \
> >> + compiletime_assert_atomic_type(*p); \
> >> + switch (sizeof(*p)) { \
> >> + case 1: \
> >> + case 2: \
> >> + __u.__val = READ_ONCE(*p); \
> >> + smb_mb(); \
> >> + break; \
> >> + case 4: \
> >> + __asm__ __volatile__ ( \
> >> + "amoor.w.aq %1, zero, %0" \
> >> + : "+A" (*p) \
> >> + : "=r" (__u.__val) \
> >> + : "memory"); \
> >> + break; \
> >> + case 8: \
> >> + __asm__ __volatile__ ( \
> >> + "amoor.d.aq %1, zero, %0" \
> >> + : "+A" (*p) \
> >> + : "=r" (__u.__val) \
> >> + : "memory"); \
> >> + break; \
> >> + } \
> >> + __u.__val; \
> >> +} while (0)
> >
> > 'creative' use of amoswap and amoor :-)
> >
> > You should really look at a normal load with ordering instruction
> > though, that amoor.aq is a rmw and will promote the cacheline to
> > exclusive (and dirty it).
>
> The thought here was that implementations could elide the MW by pattern
> matching the "zero" (x0, the architectural zero register) forms of AMOs where
> it's interesting. I talked to one of our microarchitecture guys, and while he
> agrees that's easy he points out that eliding half the AMO may wreak havoc on
> the consistency model. Since we're not sure what the memory model is actually
> going to look like, we thought it'd be best to just write the simplest code
> here
>
> /*
> * TODO_RISCV_MEMORY_MODEL: While we could emit AMOs for the W and D sized
> * accesses here, it's questionable if that actually helps or not: the lack of
> * offsets in the AMOs means they're usually preceded by an addi, so they
> * probably won't save code space. For now we'll just emit the fence.
> */
> #define __smp_store_release(p, v) \
> ({ \
> compiletime_assert_atomic_type(*p); \
> smp_mb(); \
> WRITE_ONCE(*p, v); \
> })
>
> #define __smp_load_acquire(p) \
> ({ \
> union{typeof(*p) __p; long __l;} __u; \
AFAICT, there seems to be an endian issue if you do this. No?
Let us assume typeof(*p) is char and *p == 1, and on a big endian 32bit
platform:
> compiletime_assert_atomic_type(*p); \
> __u.__l = READ_ONCE(*p); \
READ_ONCE(*p) is 1 so
__u.__l is 0x00 00 00 01 now
> smp_mb(); \
> __u.__p; \
__u.__p is then 0x00.
Am I missing something here?
Even so why not use the simple definition as in include/asm-generic/barrier.h?
Regards,
Boqun
> })
>
[...]
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
RISC-V Linux Port v4 Palmer Dabbelt <palmer@dabbelt.com> - 2017-07-04 22:00 +0200
Re: [patches] Re: [PATCH 1/9] RISC-V: Init and Halt Code Karsten Merker <merker@debian.org> - 2017-07-04 23:20 +0200
Re: [patches] Re: [PATCH 1/9] RISC-V: Init and Halt Code Thomas Gleixner <tglx@linutronix.de> - 2017-07-05 08:50 +0200
Re: [patches] [PATCH 1/9] RISC-V: Init and Halt Code Jonathan Neuschäfer <j.neuschaefer@gmx.net> - 2017-07-05 00:00 +0200
Re: [patches] [PATCH 1/9] RISC-V: Init and Halt Code Palmer Dabbelt <palmer@dabbelt.com> - 2017-07-07 00:40 +0200
Re: [patches] [PATCH 1/9] RISC-V: Init and Halt Code Jonathan Neuschäfer <j.neuschaefer@gmx.net> - 2017-07-07 15:10 +0200
Re: [patches] [PATCH 1/9] RISC-V: Init and Halt Code Palmer Dabbelt <palmer@dabbelt.com> - 2017-07-10 22:50 +0200
Re: [PATCH 2/9] RISC-V: Atomic and Locking Code Peter Zijlstra <peterz@infradead.org> - 2017-07-05 10:50 +0200
Re: [PATCH 2/9] RISC-V: Atomic and Locking Code Boqun Feng <boqun.feng@gmail.com> - 2017-07-06 06:20 +0200
Re: [PATCH 2/9] RISC-V: Atomic and Locking Code Peter Zijlstra <peterz@infradead.org> - 2017-07-06 09:30 +0200
Re: [PATCH 2/9] RISC-V: Atomic and Locking Code Palmer Dabbelt <palmer@dabbelt.com> - 2017-07-07 03:10 +0200
Re: [PATCH 2/9] RISC-V: Atomic and Locking Code Boqun Feng <boqun.feng@gmail.com> - 2017-07-07 04:20 +0200
Re: [PATCH 2/9] RISC-V: Atomic and Locking Code Palmer Dabbelt <palmer@dabbelt.com> - 2017-07-10 22:40 +0200
Re: [PATCH 2/9] RISC-V: Atomic and Locking Code Peter Zijlstra <peterz@infradead.org> - 2017-07-07 10:10 +0200
Re: [PATCH 2/9] RISC-V: Atomic and Locking Code Palmer Dabbelt <palmer@dabbelt.com> - 2017-07-10 22:40 +0200
Re: [PATCH 8/9] RISC-V: User-facing API James Hogan <james.hogan@imgtec.com> - 2017-07-05 12:30 +0200
Re: [PATCH 8/9] RISC-V: User-facing API Christoph Hellwig <hch@infradead.org> - 2017-07-06 04:10 +0200
Re: [PATCH 8/9] RISC-V: User-facing API Will Deacon <will.deacon@arm.com> - 2017-07-06 11:00 +0200
Re: [PATCH 8/9] RISC-V: User-facing API Christoph Hellwig <hch@infradead.org> - 2017-07-06 17:40 +0200
Re: [PATCH 8/9] RISC-V: User-facing API Will Deacon <will.deacon@arm.com> - 2017-07-06 17:50 +0200
Re: [PATCH 8/9] RISC-V: User-facing API Will Deacon <will.deacon@arm.com> - 2017-07-11 15:30 +0200
Re: [PATCH 8/9] RISC-V: User-facing API Christoph Hellwig <hch@infradead.org> - 2017-07-11 16:00 +0200
Re: [PATCH 8/9] RISC-V: User-facing API Palmer Dabbelt <palmer@dabbelt.com> - 2017-07-11 19:30 +0200
Re: [PATCH 8/9] RISC-V: User-facing API Palmer Dabbelt <palmer@dabbelt.com> - 2017-07-11 19:10 +0200
Re: [PATCH 2/9] RISC-V: Atomic and Locking Code Boqun Feng <boqun.feng@gmail.com> - 2017-07-06 05:40 +0200
Re: [PATCH 8/9] RISC-V: User-facing API Dave P Martin <Dave.Martin@arm.com> - 2017-07-06 17:40 +0200
Re: [patches] [PATCH 2/9] RISC-V: Atomic and Locking Code Jonathan Neuschäfer <j.neuschaefer@gmx.net> - 2017-07-07 15:20 +0200
Re: [patches] [PATCH 2/9] RISC-V: Atomic and Locking Code Palmer Dabbelt <palmer@dabbelt.com> - 2017-07-10 22:50 +0200
csiph-web