Messages in this thread | | | Date | Wed, 30 Sep 2009 20:53:15 +0200 | From | Ingo Molnar <> | Subject | Re: Linux 2.6.32-rc1 |
| |
* Linus Torvalds <torvalds@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
| |