search for: sync_rmb

...f Ry is read as 1. By design. However, it is unclear that happens in MIPS R2 1004K. Moreover, there are voices against guarantee that it will be in future and that voices point me to Documentation/memory-barriers.txt section "DATA DEPENDENCY BARRIERS" examples which require SYNC_RMB between loading address/index and using that for loading data based on that address or index for shared data (look on CPU2 pseudo-code): > To deal with this, a data dependency barrier or better must be inserted > between the address load and the data load: > > CPU 1...

...f Ry is read as 1. By design. However, it is unclear that happens in MIPS R2 1004K. Moreover, there are voices against guarantee that it will be in future and that voices point me to Documentation/memory-barriers.txt section "DATA DEPENDENCY BARRIERS" examples which require SYNC_RMB between loading address/index and using that for loading data based on that address or index for shared data (look on CPU2 pseudo-code): > To deal with this, a data dependency barrier or better must be inserted > between the address load and the data load: > > CPU 1...

...Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > >> Moreover, there are voices against guarantee that it will be in future >> and that voices point me to Documentation/memory-barriers.txt section "DATA >> DEPENDENCY BARRIERS" examples which require SYNC_RMB between loading >> address/index and using that for loading data based on that address or index >> for shared data (look on CPU2 pseudo-code): >>> To deal with this, a data dependency barrier or better must be inserted >>> between the address load and the data load: &g...

...Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote: > >> Moreover, there are voices against guarantee that it will be in future >> and that voices point me to Documentation/memory-barriers.txt section "DATA >> DEPENDENCY BARRIERS" examples which require SYNC_RMB between loading >> address/index and using that for loading data based on that address or index >> for shared data (look on CPU2 pseudo-code): >>> To deal with this, a data dependency barrier or better must be inserted >>> between the address load and the data load: &g...

...> these portable primitives (e.g. smp_mb()) in a way that satisfies the > kernel memory model so that core code doesn't need to worry about the > underlying architecture for synchronisation purposes. It seems you don't listen me. I said multiple times - MIPS implementation of SYNC_RMB/SYNC_WMB/SYNC_MB/SYNC_ACQUIRE/SYNC_RELEASE instructions matches the description of smp_rmb/smp_wmb/smp_mb/sync_acquire/sync_release from Documentation/memory-barriers.txt file. What else do you want from me - RTL or microArch design for that? - Leonid.

...> these portable primitives (e.g. smp_mb()) in a way that satisfies the > kernel memory model so that core code doesn't need to worry about the > underlying architecture for synchronisation purposes. It seems you don't listen me. I said multiple times - MIPS implementation of SYNC_RMB/SYNC_WMB/SYNC_MB/SYNC_ACQUIRE/SYNC_RELEASE instructions matches the description of smp_rmb/smp_wmb/smp_mb/sync_acquire/sync_release from Documentation/memory-barriers.txt file. What else do you want from me - RTL or microArch design for that? - Leonid.

...at 02:26:16PM -0800, Leonid Yegoshin wrote: > > > >> Moreover, there are voices against guarantee that it will be in future > >>and that voices point me to Documentation/memory-barriers.txt section "DATA > >>DEPENDENCY BARRIERS" examples which require SYNC_RMB between loading > >>address/index and using that for loading data based on that address or index > >>for shared data (look on CPU2 pseudo-code): > >>>To deal with this, a data dependency barrier or better must be inserted > >>>between the address load and t...

...the bottom of. Does the MIPS kernel target a particular CPU at compile time? > Moreover, there are voices against guarantee that it will be in future > and that voices point me to Documentation/memory-barriers.txt section "DATA > DEPENDENCY BARRIERS" examples which require SYNC_RMB between loading > address/index and using that for loading data based on that address or index > for shared data (look on CPU2 pseudo-code): > >To deal with this, a data dependency barrier or better must be inserted > >between the address load and the data load: > > > &gt...

On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > So SYNC_RMB is intended to implement smp_rmb(), correct? Yes. > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. If smp_read_barrier_depends() is used to separate not only two reads but read pointer and WRITE...

On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > So SYNC_RMB is intended to implement smp_rmb(), correct? Yes. > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. If smp_read_barrier_depends() is used to separate not only two reads but read pointer and WRITE...

On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > > Yes. > > > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > >smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > > > If smp_read_barrier_depends() is used...

On Thu, Jan 14, 2016 at 02:20:46PM -0800, Paul E. McKenney wrote: > On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > > Yes. > > > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > >smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > > > If smp_read_barrier_depends() is used...

...e.g. smp_mb()) in a way that > >satisfies the kernel memory model so that core code doesn't need > >to worry about the underlying architecture for synchronisation > >purposes. > > It seems you don't listen me. I said multiple times - MIPS > implementation of > SYNC_RMB/SYNC_WMB/SYNC_MB/SYNC_ACQUIRE/SYNC_RELEASE instructions > matches the description of > smp_rmb/smp_wmb/smp_mb/sync_acquire/sync_release from > Documentation/memory-barriers.txt file. > > What else do you want from me - RTL or microArch design for that? I suspect that it is more lik...

...for smp_*() sort of > memory barriers in MIPS R2/R3/R5 and R6. > > Unfortunately, it's description is very cryptic and is done in HW engineering > style which prevents use of it by SW. 3. I bother MIPS Arch team long time until I completely understood that MIPS SYNC_WMB, SYNC_MB, SYNC_RMB, SYNC_RELEASE and SYNC_ACQUIRE do an exactly that is required in Documentation/memory-barriers.txt In Peter Zijlstra mail: > 1) you do not make such things selectable; either the hardware needs > them or it doesn't. If it does you_must_ use them, however unlikely. It is selectable on...

Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote: > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > The reason for this is that smp_read_barrier_depends() must order the > pointer load against any subsequent read or write through a dereference > of that pointer. For example: > > p = READ_ONCE(gp); > smp_rmb(); > r1 = p->a...

Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote: > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > The reason for this is that smp_read_barrier_depends() must order the > pointer load against any subsequent read or write through a dereference > of that pointer. For example: > > p = READ_ONCE(gp); > smp_rmb(); > r1 = p->a...

...s() and > smp_rmb() should be used instead. Is SYNC_ACQUIRE a memory-barrier instruction that orders prior loads against later loads and stores? If so, and if MIPS does not do ordering based on address and data dependencies, I suggest making read_barrier_depends() be a SYNC_ACQUIRE rather than SYNC_RMB. Thanx, Paul

...s() and > smp_rmb() should be used instead. Is SYNC_ACQUIRE a memory-barrier instruction that orders prior loads against later loads and stores? If so, and if MIPS does not do ordering based on address and data dependencies, I suggest making read_barrier_depends() be a SYNC_ACQUIRE rather than SYNC_RMB. Thanx, Paul

On Thu, Jan 14, 2016 at 01:24:34PM -0800, Leonid Yegoshin wrote: > On 01/14/2016 12:48 PM, Paul E. McKenney wrote: > > > >So SYNC_RMB is intended to implement smp_rmb(), correct? > Yes. > > > >You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > >smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > If smp_read_barrier_depends() is used to separate not only two reads...

...McKenney wrote: > On Mon, Jan 18, 2016 at 04:19:29PM +0800, Herbert Xu wrote: > > Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote: > > > > > > You could use SYNC_ACQUIRE() to implement read_barrier_depends() and > > > smp_read_barrier_depends(), but SYNC_RMB probably does not suffice. > > > The reason for this is that smp_read_barrier_depends() must order the > > > pointer load against any subsequent read or write through a dereference > > > of that pointer. For example: > > > > > > p = READ_ONCE(gp...