search for: sync_acquire

...are and improve the Linux memory model. > > I am afraid I can't help you here. It is very complicated stuff and > a model is actually doesn't fit your assumptions about CPUs well > without some simplifications which are based on what you want to > have. > > I say that SYNC_ACQUIRE/etc follows what you expect for smp_acquire > etc (basing on that document). And at least two CPU models were > tested with my patches (see it in LMO) for that last year and that > instructions are implemented now in engineering kernel. > > If you have something else in mind, you ca...

...are and improve the Linux memory model. > > I am afraid I can't help you here. It is very complicated stuff and > a model is actually doesn't fit your assumptions about CPUs well > without some simplifications which are based on what you want to > have. > > I say that SYNC_ACQUIRE/etc follows what you expect for smp_acquire > etc (basing on that document). And at least two CPU models were > tested with my patches (see it in LMO) for that last year and that > instructions are implemented now in engineering kernel. > > If you have something else in mind, you ca...

...itives (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.

...itives (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 > >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 likely that we are talking past e...

...he Linux memory model. >> I am afraid I can't help you here. It is very complicated stuff and >> a model is actually doesn't fit your assumptions about CPUs well >> without some simplifications which are based on what you want to >> have. >> >> I say that SYNC_ACQUIRE/etc follows what you expect for smp_acquire >> etc (basing on that document). And at least two CPU models were >> tested with my patches (see it in LMO) for that last year and that >> instructions are implemented now in engineering kernel. >> >> If you have something e...

...t; >>I am afraid I can't help you here. It is very complicated stuff and > >>a model is actually doesn't fit your assumptions about CPUs well > >>without some simplifications which are based on what you want to > >>have. > >> > >>I say that SYNC_ACQUIRE/etc follows what you expect for smp_acquire > >>etc (basing on that document). And at least two CPU models were > >>tested with my patches (see it in LMO) for that last year and that > >>instructions are implemented now in engineering kernel. > >> > >>If...

...t; >>I am afraid I can't help you here. It is very complicated stuff and > >>a model is actually doesn't fit your assumptions about CPUs well > >>without some simplifications which are based on what you want to > >>have. > >> > >>I say that SYNC_ACQUIRE/etc follows what you expect for smp_acquire > >>etc (basing on that document). And at least two CPU models were > >>tested with my patches (see it in LMO) for that last year and that > >>instructions are implemented now in engineering kernel. > >> > >>If...

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 examp...

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 examp...

On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > An the only point - please use an appropriate SYNC_* barriers instead of > heavy bold hammer. That stuff was design explicitly to support the > requirements of Documentation/memory-barriers.txt That's madness. That document changes from version to version as to what we _think_ the actual hardware does. It is _NOT_ a

On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote: > An the only point - please use an appropriate SYNC_* barriers instead of > heavy bold hammer. That stuff was design explicitly to support the > requirements of Documentation/memory-barriers.txt That's madness. That document changes from version to version as to what we _think_ the actual hardware does. It is _NOT_ a

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 basing on that pointer (example below) - yes. I just doesn't see any example of t...

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 basing on that pointer (example below) - yes. I just doesn't see any example of t...

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 > but read pointer and WRITE basing on that pointer (example below) - > yes. I just doesn'...

On 01/13/2016 12:48 PM, Peter Zijlstra wrote: > On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: > >> I ask HW team about it but I have a question - has it any relationship with >> replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)? > Of course. If you cannot explain the semantics of the primitives you > introduce, how can we judge the patch. >

On 01/13/2016 12:48 PM, Peter Zijlstra wrote: > On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote: > >> I ask HW team about it but I have a question - has it any relationship with >> replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)? > Of course. If you cannot explain the semantics of the primitives you > introduce, how can we judge the patch. >

...00, 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 to separate not only two reads > > but read pointer and WRITE basing on that pointer (example below) - > &g...

...00, 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 to separate not only two reads > > but read pointer and WRITE basing on that pointer (example below) - > &g...

Hi Paul, On Mon, Jan 18, 2016 at 07:46:29AM -0800, Paul E. 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 &g...