Messages in this thread | | | Date | Tue, 22 Apr 2003 01:56:54 +0200 | From | Andi Kleen <> | Subject | Re: [PATCH] Runtime memory barrier patching II |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |