Re: [PATCH] um: allow using glibc string functions instead of generics

[Anton Ivanov <anton.ivanov@cambridgegreys.com>]

On 11/11/2020 15:14, Anton Ivanov wrote:
>
> On 11/11/2020 07:13, Anton Ivanov wrote:
>> On 10/11/2020 21:39, Richard Weinberger wrote:
>>> ----- Ursprüngliche Mail -----
>>>> Von: "anton ivanov" <anton.ivanov@cambridgegreys.com>
>>>> An: "richard" <richard@nod.at>
>>>> CC: "linux-um" <linux-um@lists.infradead.org>
>>>> Gesendet: Dienstag, 10. November 2020 22:33:48
>>>> Betreff: Re: [PATCH] um: allow using glibc string functions instead of generics
>>>
>>>> On 10/11/2020 21:29, Richard Weinberger wrote:
>>>>> ----- Ursprüngliche Mail -----
>>>>>> Von: "anton ivanov" <anton.ivanov@cambridgegreys.com>
>>>>>>> On what workload did you see such a huge performance improvement?
>>>>>> File IO ~ 1% or thereabouts, iperf - 2-4%.
>>>>>>
>>>>>>> The in-kernel variants of memcpy and such are already well optimized.
>>>>>> UML has no string.h in asm which means it falls back to
>>>>>> asm-generic/string.h which in turn pulls in the ones from lib/string.c
>>>>>>
>>>>>> These are not optimized.
>>>>> Hmmm, I think it should use the highly optimized variants from arch/x86.
>>>>
>>>> That is the other option - to bring in string32.h and string64.h from x86.
>>>
>>> Yes, I thought we do so already. I fear we list this feature after some code
>>> cleanup a long time ago.
>>>
>>> I'm happy with either option.
>>
>> I will have a look if we lost other optimized code as a result of the asm cleanup and sort it out in the next version.
>>
>> The advantage of glibc is that it is guaranteed to chose the correct flavor for the CPU.
>>
>> I do not think that this the case for the kernel ones, because they rely on boottime CPU features detection which does not happen in the case of UML. So in order to use them properly, we may have to implement that.
>>
>> Otherwise, the code in the glibc tree and in the kernel is nearly identical. Just glibc was easier as it did not require figuring out CPU detection :)
>
> I did XOR, the difference on its own benchmarks on my machine is 117%.
>
> That was the relatively easy part.
>
> We have issues applying the same approach to checksum.h
>
> 1. The x86 checksum_32.h and checksum_64.h files do not ifdef with the appropriate ifdefs csum_and_copy_from_user() and to_user. In order to use these instead of our own copies, we need to add the missing ifdefs.
>
> 2. Checksum needs tidyng up. Both 32 bit and 64 bit versions of UML bring in an old copy of the 32 bit x86 checksum which has been duplicated into arch/x86/um. There is some 64 bit code which unless I am mistaken is never pulled in because it is still ifdefed on CONFIG_X86_32 instead of CONFIG_64BIT
>
> string.h looks more straight forward, I will probably do it next leaving cksum last.

I managed to untangle checksum so it 100% works using x86 "upstream" files and I have a working version, but I will need some testing for 32/64 bit cases to make sure it is OK.

I will probably push it before the end of the week.

A.

>
> A.
>
>
>>
>>>
>>> Thanks,
>>> //richard
>>>
>>> _______________________________________________
>>> linux-um mailing list
>>> linux-um@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/


_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um