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 sense, but it's still very annoying for
> something
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 Maci
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 Maci
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:
> > > >
> > > > You might as well j
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 human) incomplete. This
>
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 0
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 request, where now diffe
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| 9 +
> >
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 +
> tools/virtio/ringtest/ma
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 481eaec37e91e2b33f17275901
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 right for x86-64.
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?
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:
ht
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.
Si
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
Signed-
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 c
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 caller
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
doc
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 memory barriers provided
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 changing.
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' :-)
__
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* case
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 penalty
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 0
On Wed, 13 Jan 2016 18:09:34 +0100
Greg Kurz wrote:
> This series is a respin of the following patch:
>
> http://patchwork.ozlabs.org/patch/565921/
>
> Patch 1 is preliminary work: it gives better names to the helpers that are
> involved in cross-endian support.
>
> Patch 2 is actually a v2 of
On Tue, Jan 26, 2016 at 03:37:33PM -0800, Paul E. McKenney wrote:
> On Tue, Jan 26, 2016 at 12:10:10PM +, Will Deacon wrote:
> > On Mon, Jan 25, 2016 at 05:06:46PM -0800, Paul E. McKenney wrote:
> > > PPC WRCnf+addrs
> > > ""
> > > {
> > > 0:r2=x; 0:r3=y;
> > > 1:r2=x; 1:r3=y;
> > > 2:r2=x; 2:r
On Wed, Jan 27, 2016 at 09:35:46AM +0100, Peter Zijlstra wrote:
> 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
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
> > RELEASE/ACQUIR
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
building
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 cache award"
thing, and a
30 matches
Mail list logo