[PATCH v4 2/7] um: enable the use of optimized xor routines in UML

Johannes Berg johannes at sipsolutions.net
Fri Dec 11 17:00:12 EST 2020


On Fri, 2020-12-11 at 21:57 +0000, Anton Ivanov wrote:
> 
> > > --- /dev/null
> > > +++ b/arch/um/include/asm/xor-x86.h
> > > @@ -0,0 +1 @@
> > > +../../../x86/include/asm/xor.h
> > Do these really need to be symlinks? Last I looked, it seemed that
> > arch/x86/include/asm/ is actually in the include path?
> 
> It is included, but it is included quite far down the list.

I see. So you're saying basically we'll get asm-generic/xor.h before the
x86 version, and then we're getting the worst possible implementation,
right?

> We pick up a few things out of there, but if we leave them "as is" they 
> all default to their least optimized versions. The results clearly 
> demonstrate that too - 30% difference on 64 bit and > 100% on 32 bit.

Right.

> This is because we do not perform alternatives substitution. Our 
> "alternatives" processing function in the UML startup is a noop.

Oh, so we *do* get x86, but compatibility with ancient CPUs?

> My idea was to override that to the extent possible and get whatever 
> mileage is possible without that.

Makes sense.

> I can give it a try to see how it looks if I use the x86 feature table 
> and other bits which are picked up from there, but working with that is 
> like pulling teeth without anaesthetic.
> 
> On the positive side this means that we can copy the alternatives code 
> on x86.
> 
> I can give it another go. I tried early on and it was a bit painful.

Yeah, no, not sure ...

Maybe just doing something like

#include "../../../x86/include/asm/xor.h"

would be acceptable? It seems a bit better to me in the sense of being
more obvious than the symlinks... but dunno.

johannes




More information about the linux-um mailing list