[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