search for: sync_wmb

Displaying 16 results from an estimated 16 matches for "sync_wmb".

Did you mean: sync_rmb
2016 Jan 13
3
[v3,11/41] mips: reuse asm-generic/barrier.h
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. > > You missed a point - it is a question about replacement of SYNC with lightweight primitives. It is NOT a question about multithread system behavior without any SYN...
2016 Jan 13
3
[v3,11/41] mips: reuse asm-generic/barrier.h
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. > > You missed a point - it is a question about replacement of SYNC with lightweight primitives. It is NOT a question about multithread system behavior without any SYN...
2016 Jan 13
2
[v3,11/41] mips: reuse asm-generic/barrier.h
...ess dep> > Rx = 0 > > > So are you saying that this is also forbidden? > Imagine that P0 and P1 are two threads that share a store buffer. What > then? > 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)? You use any barrier or do not use it and I just voice an intention to use a more efficient instruction instead of bold hummer (SYNC instruction). If you don't use any barrier here then it is a different issue. May be it has sense to return back to original issue? - Leonid
2016 Jan 13
2
[v3,11/41] mips: reuse asm-generic/barrier.h
...ess dep> > Rx = 0 > > > So are you saying that this is also forbidden? > Imagine that P0 and P1 are two threads that share a store buffer. What > then? > 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)? You use any barrier or do not use it and I just voice an intention to use a more efficient instruction instead of bold hummer (SYNC instruction). If you don't use any barrier here then it is a different issue. May be it has sense to return back to original issue? - Leonid
2016 Jan 14
2
[v3,11/41] mips: reuse asm-generic/barrier.h
...gt; 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. > > > > > > > > You missed a point - it is a question about replacement of SYNC with > > lightweight primitives. It is NOT a qu...
2016 Jan 14
2
[v3,11/41] mips: reuse asm-generic/barrier.h
...gt; 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. > > > > > > > > You missed a point - it is a question about replacement of SYNC with > > lightweight primitives. It is NOT a qu...
2016 Jan 14
3
[v3,11/41] mips: reuse asm-generic/barrier.h
...ese 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.
2016 Jan 14
3
[v3,11/41] mips: reuse asm-generic/barrier.h
...ese 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.
2016 Jan 12
3
[v3,11/41] mips: reuse asm-generic/barrier.h
...ly designed to work 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....
2016 Jan 13
0
[v3,11/41] mips: reuse asm-generic/barrier.h
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. This barrier business is hard enough as it is, but magic unexplained hardware makes it impossible. Rest assured, you (MIPS) isn't the first (nor likely the last) to go through al...
2016 Jan 14
0
[v3,11/41] mips: reuse asm-generic/barrier.h
...id Yegoshin wrote: > 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. > > > > > You missed a point - it is a question about replacement of SYNC with > lightweight primitives. It is NOT a question about multithread syste...
2016 Jan 14
0
[v3,11/41] mips: reuse asm-generic/barrier.h
...3/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. >>>> >>>> >>> You missed a point - it is a question about replacement of SYNC with >>> lightweight primitives...
2016 Jan 14
0
[v3,11/41] mips: reuse asm-generic/barrier.h
...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 likely that...
2016 Jan 12
3
[v3,11/41] mips: reuse asm-generic/barrier.h
On Tue, Jan 12, 2016 at 11:40:12AM +0100, Peter Zijlstra wrote: > On Tue, Jan 12, 2016 at 11:25:55AM +0100, Peter Zijlstra wrote: > > On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > > > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > > > 0x12 semantics nor does it provide a publicly accessible link to > > > documentation
2016 Jan 12
3
[v3,11/41] mips: reuse asm-generic/barrier.h
On Tue, Jan 12, 2016 at 11:40:12AM +0100, Peter Zijlstra wrote: > On Tue, Jan 12, 2016 at 11:25:55AM +0100, Peter Zijlstra wrote: > > On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > > > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > > > 0x12 semantics nor does it provide a publicly accessible link to > > > documentation
2016 Jan 12
0
[v3,11/41] mips: reuse asm-generic/barrier.h
...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 Ha! and you think that document covers all the really fun details? In particular we're very much all 'confused' about the various notions of transitivity and what...