[PATCH v2] um: enable the use of optimized xor routines in UML

[Anton Ivanov]

On 12/11/2020 14:18, Anton Ivanov wrote:
> 
> On 12/11/2020 11:09, Richard Weinberger wrote:
>> Anton,
>>
>> ----- Ursprüngliche Mail -----
>>> Von: "anton ivanov" <anton.ivanov at cambridgegreys.com>
>>> An: "linux-um" <linux-um at lists.infradead.org>
>>> CC: "richard" <richard at nod.at>, "anton ivanov" <anton.ivanov at cambridgegreys.com>
>>> Gesendet: Donnerstag, 12. November 2020 11:33:37
>>> Betreff: [PATCH v2] um: enable the use of optimized xor routines in UML
>>> From: Anton Ivanov <anton.ivanov at cambridgegreys.com>
>>>
>>> This patch enable the use of optimized xor routines from the x86
>>> tree as well as supply the necessary macros for them to be used in
>>> UML.
>>>
>>> The macros supply several "fake" flags and definitions to allow
>>> using the x86 files "as is".
>>>
>>> This patchset implements only the flags needed for the optimized
>>> strings.h, xor.h and checksum.h implementations instead of
>>> trying to copy the entire x86 flags environment.
>> So, the plan is using xor methods from arch/x86 and string methods
>> from glibc?
> 
> Atomics also need to come from arch/x86. That is another one. We fall back to generic atomics which are along the lines of:
> 
> interrupts_off
> 
> do atomic op
> 
> interrupts_on
> 
> That is very expensive especially compared to an existing proper atomic op.
> 
> We can do it only on 64 bit though, the 64 bit atomics on 32bit x86 use alternatives to switch between versions - it is the same problem as with string.h
> 
> This squeezes a few cycles here and there too. It is not particularly noticeable though. The gain is within "experimental error".
> 
> Patch will follow shortly.

There are two more.

One is easy - barrier.h

We can just steal it from the x86 tree for the 64 bit case. Same story with alternatives apply for the 32 bit case. Patch coming up shortly.

The other one is futex. The generic one does not implement all ops causing workarounds at higher layers and is fairly expensive. How much - difficult to say as I do not know how much does it cost to glibc to workaround the ENOSYS it returns on some of the atomic ops.

In the parts which are implemented it does:

get_user - this results in:
	page_in
	uaccess_check()
attempt at an atomic op on value from get_user
put_user on the result - this results in
	page_in
	uaccess_check

While it should be
page_in
uaccess_check()
atomic_op() directly on futex target address

This one will be harder and will take some time and it will rely on having real barriers and atomics (the other patches as a prerequisite).

Based on looking at what we are picking up from asm-generic, this should be about it. We have the rest implemented already and/or the asm-generic and lib/ functions are as good as any potential replacement.

> 
>>
>> Thanks,
>> //richard
>>
>> _______________________________________________
>> linux-um mailing list
>> linux-um at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-um
> 

-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/