Re: [PATCH] Runtime memory barrier patching II

[Andi Kleen <ak@muc.de>]

On Tue, Apr 22, 2003 at 01:46:11AM +0200, Andi Kleen wrote:
> On Tue, Apr 22, 2003 at 01:35:57AM +0200, Jamie Lokier wrote:
> > Andi Kleen wrote:
> > > The patching code is quite generic and could be used to patch other
> > > instructions
> > 
> > Such as removing the lock prefix when running non-SMP?
> 
> Yes, could work. But you need a new variant of alternative()

Thinking about it will need more work, making it much harder:

- you need to move it after the CPU detection because before
you don't know how many CPUs are there or not.

- you need to define a new pseudo X86 feature bit for SMP active

- you can't easily put an assembly "i" argument into the LOCK_PREFIX
macro, so you have to hardcode the feature bit in there 
(not difficult, but ugly)

First part is somewhat nasty which makes it look not too attractive.
Before doing the necessary changes for that someone (= not me) 
should probably do some benchmarks first to see if it's worth it
at all. I suspect it is on the P4.

But: all the distributions I'm aware of install separate SMP 
and UP kernels. So it wouldn't be a big improvement for them.
And the other users likely compile a custom kernel anyways.

> or eat worse code. The current alternative() can only handle
> constant sized original instructions, which requires that you
> use a constant sized constraint (e.g. (%0) ... "r" (ptr)) etc.)
> "m" is unfortunately variable size.

Actually that was a bit too strict. It can deal with longer
code (the patch code will transparently nop that), just not with shorter
paths.

-Andi