On Thu, Jan 14, 2016 at 12:04:45PM +0000, Will Deacon wrote:> On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid 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 system > > behavior without any SYNC. The answer on a latest Will's question lies in > > different area. > > The reason we (Peter and I) care about this isn't because we enjoy being > obstructive. It's because there is a whole load of core (i.e. portable) > kernel code that is written to the *kernel* memory model. For example, > the scheduler, RCU, mutex implementations, perf, drivers, you name it. > > Consequently, it's important that the architecture back-ends implement > 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. You could turn > around and say "but if MIPS gets it wrong, then that's MIPS's problem", > but actually not having a general understanding of the ordering guarantees > provided by each architecture makes it very difficult for us to extend > the kernel memory model in such a way that it can be implemented > efficiently across the board *and* relied upon by core code.What Will said! Yes, you can cut corners within MIPS architecture-specific code, but primitives that are used in the core kernel really do need to work as expected. Thanx, Paul> The virtio patch at the start of the thread doesn't particularly concern > me. It's the other patches you linked to that implement acquire/release > that have me worried. > > Will >
On 01/14/2016 08:16 AM, Paul E. McKenney wrote:> On Thu, Jan 14, 2016 at 12:04:45PM +0000, Will Deacon wrote: >> On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid 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 system >>> behavior without any SYNC. The answer on a latest Will's question lies in >>> different area. > What Will said! > > Yes, you can cut corners within MIPS architecture-specific code, > but primitives that are used in the core kernel really do need to > work as expected. > > Thanx, Paul > >Absolutelly! Please use SYNC - right now it is not. 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 It is easy - just use smp_acquire instead of plain smp_mb insmp_load_acquire, at least for MIPS. - Leonid. - Leonid.
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.txtThat's madness. That document changes from version to version as to what we _think_ the actual hardware does. It is _NOT_ a specification. You cannot design hardware from that. Its incomplete and fails to specify a bunch of things. It not a mathematically sound definition of a memory model. Please stop referring to that document for what a particular barrier _should_ do. Explain what MIPS does, so we can attempt to integrate this knowledge with our knowledge of PPC/ARM/Alpha/x86/etc. and improve upon our understanding of hardware and improve the Linux memory model.