Re: [PULL] virtio: fixes, tests

On Wed, Jan 27, 2016 at 11:57:52AM -0800, Linus Torvalds wrote: > On Wed, Jan 27, 2016 at 11:12 AM, Michael S. Tsirkin wrote: > > > > arch/sh/include/asm/barrier.h| 1 - > > tools/virtio/asm/barrier.h | 22 +- > > tools/virtio/linux/compiler.h

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Wed, Jan 27, 2016 at 10:04:47AM +0800, Boqun Feng wrote: > On Tue, Jan 26, 2016 at 03:29:21PM -0800, Paul E. McKenney wrote: > > On Tue, Jan 26, 2016 at 02:33:40PM -0800, Linus Torvalds wrote: > > > On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds > > > wrote: > >

Re: [PULL] virtio: fixes, tests

On Wed, Jan 27, 2016 at 2:15 PM, Michael S. Tsirkin wrote: >> >> Anyway, pulled. Just curious about how that thing happened. > > That's because apparently diffstat obeys orderfile rules: Ugh. I guess that makes sense, but it's still very annoying for something like a pull

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote: On Fri, 15 Jan 2016, Leonid Yegoshin wrote: So you need to build a different kernel for some types of MIPS systems? Or do you do boot-time rewriting, like a number of other arches do? I don't know. I would like to have responses. Ralf asked

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Wed, Jan 27, 2016 at 10:25:46AM +, Will Deacon wrote: > On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote: > > On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote: > > > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > > > On Mon, Jan 25, 2016 at

Re: [PATCH] documentation: Add disclaimer

On Wed, Jan 27, 2016 at 02:57:07PM +, David Howells wrote: > Peter Zijlstra wrote: > > > +== > > +DISCLAIMER > > +== > > + > > +This document is not a specification; it is intentionally (for the sake of > > +brevity) and unintentionally (due to being

Re: [PULL] virtio: fixes, tests

Linus Torvalds writes: > On Wed, Jan 27, 2016 at 2:15 PM, Michael S. Tsirkin wrote: >>> >>> Anyway, pulled. Just curious about how that thing happened. >> >> That's because apparently diffstat obeys orderfile rules: > > Ugh. I guess that makes

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote: On Fri, 15 Jan 2016, Leonid Yegoshin wrote: So you need to build a different kernel for some types of MIPS systems? Or do you do boot-time rewriting, like a number of other arches do? I don't know. I would like to have responses. Ralf asked

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Jan 26, 2016 23:51, "Peter Zijlstra" wrote: > > So for a moment it looked like MIPS wanted to equal or surpass Alpha in > this respect. If there is an architecture that I'd expect to try to take the "sucks more" crown, MIPS would be it. They've already done the "worst

[PATCH v4 4/5] x86: use mb() around clflush

commit f8e617f4582995f7c25ef25b4167213120ad122b ("sched/idle/x86: Optimize unnecessary mwait_idle() resched IPIs") adds memory barriers around clflush, but this seems wrong for UP since barrier() has no effect on clflush. We really want mfence so switch to mb() instead. Cc: Mike Galbraith

Re: [PATCH v4 5/5] x86: drop mfence in favor of lock+addl

On Wed, Jan 27, 2016 at 7:10 AM, Michael S. Tsirkin wrote: > > -#define __smp_mb() mb() > +#define __smp_mb() asm volatile("lock; addl $0,-4(%%esp)" ::: "memory", > "cc") So this doesn't look right for x86-64. Using %esp rather than %rsp. How did that even work for you?

Re: [PATCH v4 5/5] x86: drop mfence in favor of lock+addl

On Wed, Jan 27, 2016 at 09:37:45AM -0800, Linus Torvalds wrote: > On Wed, Jan 27, 2016 at 7:10 AM, Michael S. Tsirkin wrote: > > > > -#define __smp_mb() mb() > > +#define __smp_mb() asm volatile("lock; addl $0,-4(%%esp)" ::: > > "memory", "cc") > > So this doesn't look

[PULL] virtio: fixes, tests

The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d: Linux 4.5-rc1 (2016-01-24 13:06:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus for you to fetch changes up to

Re: [PULL] virtio: fixes, tests

On Wed, Jan 27, 2016 at 11:12 AM, Michael S. Tsirkin wrote: > > arch/sh/include/asm/barrier.h| 1 - > tools/virtio/asm/barrier.h | 22 +- > tools/virtio/linux/compiler.h| 9 + > tools/virtio/linux/kernel.h | 1 + >

[PATCH] documentation: Add disclaimer

On Tue, Jan 26, 2016 at 12:11:43PM -0800, Paul E. McKenney wrote: > So Peter, would you like to update your patch to include yourself > and Will as authors? Sure, here goes. --- Subject: documentation: Add disclaimer It appears people are reading this document as a requirements list for

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 12:13:39PM -0800, Paul E. McKenney wrote: > On Tue, Jan 26, 2016 at 11:19:27AM +0100, Peter Zijlstra wrote: > > So isn't smp_mb__after_unlock_lock() exactly such a scenario? And would > > not someone trying to implement RCsc locks using locally transitive > >

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Thu, Jan 14, 2016 at 04:47:53PM -0800, Paul E. McKenney wrote: > So you need to build a different kernel for some types of MIPS systems? Yes. We can't really do without. Classic MIPS code is not relocatable without the complexity of PIC code as used by ELF DSOs - and their performanc

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 11:58:20AM -0800, Paul E. McKenney wrote: > On Tue, Jan 26, 2016 at 12:16:09PM +, Will Deacon wrote: > > On Mon, Jan 25, 2016 at 10:03:22PM -0800, Paul E. McKenney wrote: > > > On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote: > > > > On Fri, Jan 15, 2016 at

Re: [PATCH v2 0/3] x86: faster mb()+other barrier.h tweaks

On Tue, Jan 26, 2016 at 01:37:38PM -0800, H. Peter Anvin wrote: > On 01/26/16 00:20, Michael S. Tsirkin wrote: > > On Tue, Jan 12, 2016 at 02:25:24PM -0800, H. Peter Anvin wrote: > > > > Hi hpa, > > Any luck getting some feedback on this one? > > > > Yes. What we know so far is that *most*

Re: [PATCH v2 0/3] x86: faster mb()+other barrier.h tweaks

On Wed, Jan 27, 2016 at 04:07:56PM +0200, Michael S. Tsirkin wrote: > mwait_idle is the only one that calls smp_mb and not mb() > I couldn't figure out why - original patches did mb() > there. That probably wants changing. That said, running UP kernels on affected hardware is 'unlikely' :-)

Re: [PATCH v2 0/3] x86: faster mb()+other barrier.h tweaks

On Wed, Jan 27, 2016 at 03:14:09PM +0100, Peter Zijlstra wrote: > On Wed, Jan 27, 2016 at 04:07:56PM +0200, Michael S. Tsirkin wrote: > > mwait_idle is the only one that calls smp_mb and not mb() > > I couldn't figure out why - original patches did mb() > > there. > > That probably wants

Re: [PATCH] documentation: Add disclaimer

Peter Zijlstra wrote: > +== > +DISCLAIMER > +== > + > +This document is not a specification; it is intentionally (for the sake of > +brevity) and unintentionally (due to being human) incomplete. This document > is > +meant as a guide to using the various

[PATCH v4 1/5] x86: add cc clobber for addl

addl clobbers flags (such as CF) but barrier.h didn't tell this to gcc. Historically, gcc doesn't need one on x86, and always considers flags clobbered. We are probably missing the cc clobber in a *lot* of places for this reason. But even if not necessary, it's probably a good thing to add for

[PATCH v4 0/5] x86: faster smp_mb()+documentation tweaks

mb() typically uses mfence on modern x86, but a micro-benchmark shows that it's 2 to 3 times slower than lock; addl that we use on older CPUs. So we really should use the locked variant everywhere, except that intel manual says that clflush is only ordered by mfence, so we can't. Note: some

[PATCH v4 2/5] x86: drop a comment left over from X86_OOSTORE

The comment about wmb being non-nop to deal with non-intel CPUs is a left over from before commit 09df7c4c8097 ("x86: Remove CONFIG_X86_OOSTORE"). It makes no sense now: in particular, wmb is not a nop even for regular intel CPUs because of weird use-cases e.g. dealing with WC memory. Drop this

[PATCH v4 3/5] x86: tweak the comment about use of wmb for IO

On x86, we *do* still use the non-nop rmb/wmb for IO barriers, but even that is generally questionable. Leave them around as historial unless somebody can point to a case where they care about the performance, but tweak the comment so people don't think they are strictly required in all cases.

[PATCH v4 5/5] x86: drop mfence in favor of lock+addl

mfence appears to be way slower than a locked instruction - let's use lock+add unconditionally, as we always did on old 32-bit. Just poking at SP would be the most natural, but if we then read the value from SP, we get a false dependency which will slow us down. This was noted in this article: