Linux 2.6.32-rc1
in [Kernel]
|
From: Arjan van de Ven on 30 Sep 2009 12:20 On Wed, 30 Sep 2009 17:57:25 +0200 Eric Dumazet <eric.dumazet(a)gmail.com> wrote: > > Note: > > lock; cmpxchg8b (%%esi) > > gives 4 bytes opcode : f0 0f c7 0e > Because alternative (call cmpxchg8b_emu) uses 5 bytes, a nop will be > added. > > Choosing ".byte 0xf0, 0x0f, 0xc7, 0x4e, 0x00" aka "lock cmpxchg8b > 0x0(%esi)" is a litle bit better ? doesn't matter normally.. nops fall out quickly in the execution path ;) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Richter on 30 Sep 2009 13:00 Arjan van de Ven wrote: > Subject: [PATCH] x86: Provide an alternative() based cmpxchg64() > > Based on Linus' patch, this patch provides cmpxchg64() using > the alternative() infrastructure. > > Note: the fallback is NOT smp safe, just like the current fallback > is not SMP safe. As long as it can't be turned into an atomic access, shouldn't cmpxchg64 be hidden from the common kernel coder? Almost everybody will assume that it is an atomic operation and happily use it in unsafe places. -- Stefan Richter -=====-==--= =--= ====- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 30 Sep 2009 13:20 On Wed, 30 Sep 2009, Stefan Richter wrote: > > As long as it can't be turned into an atomic access, shouldn't cmpxchg64 > be hidden from the common kernel coder? Almost everybody will assume > that it is an atomic operation and happily use it in unsafe places. But it _is_ atomic. We don't support SMP on the platforms that we have to do it with emulation on. There's a theoretical problem with NMI, but it's not one we can solve or that is really all that interesting, so might as well ignore it. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Stefan Richter on 30 Sep 2009 13:50 Linus Torvalds wrote: > On Wed, 30 Sep 2009, Stefan Richter wrote: >> As long as it can't be turned into an atomic access, shouldn't cmpxchg64 >> be hidden from the common kernel coder? Almost everybody will assume >> that it is an atomic operation and happily use it in unsafe places. > > But it _is_ atomic. We don't support SMP on the platforms that we have to > do it with emulation on. > > There's a theoretical problem with NMI, but it's not one we can solve or > that is really all that interesting, so might as well ignore it. Ah, right, I could have taken a hint from /* disable interrupts */ in Arjan's cmpxchg8b_emu. -- Stefan Richter -=====-==--= =--= ====- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 30 Sep 2009 15:00
* Linus Torvalds <torvalds(a)linux-foundation.org> wrote: > On Wed, 30 Sep 2009, Eric Dumazet wrote: > > > > lock; cmpxchg8b (%%esi) > > > > gives 4 bytes opcode : f0 0f c7 0e > > Because alternative (call cmpxchg8b_emu) uses 5 bytes, a nop will be added. > > > > Choosing ".byte 0xf0, 0x0f, 0xc7, 0x4e, 0x00" aka "lock cmpxchg8b 0x0(%esi)" is a litle bit better ? > > And if you want to be really clever, you would want to handle the > non-SMP case too, where you have just "cmpxchgb (%%esi)" (three bytes) > without the lock prefix. > > However, at this point I think Arjan's patch is already way superior > to what we have now (feel free to take a look at what we generate on > 32-bit without PAE today - just have a barf-bag handy), so all I'd > really want is a few "tested-by"s to make me feel happier about it, > and a few more people looking at the emulation routine to all say "ok, > looks sane, ACK". > > And at that point we can then either make "cmpxchg()" just do the > 8-byte case natively, or just take your patch to change sched_clock.c > to now use the no-longer-entirely-disgusting cmpxchg64(). > > Ingo - I suspect both those patches should just go through you. You do > both x86 and scheduler, so I'll happily pull the end result. Yeah - working on it - just got back from a trip. It's two risky patches and if that place breaks everyone will be affected so i'll probably send the pull request tomorrow. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |