um: "borrow" cmpxchg from x86 tree in UML

From: Anton Ivanov <anton.ivanov@cambridgegreys.com>

UML was falling back to asm-generic cmpxchg which emulates atomic
behaviour by turning irqs on/off. On UML this means turning
on/off signals for each cmpxchg which is expensive.

Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
---
 arch/um/include/asm/cmpxchg-x86.h |  1 +
 arch/um/include/asm/cmpxchg.h     | 13 +++++++++++++
 arch/um/include/asm/cmpxchg_32.h  |  1 +
 arch/um/include/asm/cmpxchg_64.h  |  1 +
 4 files changed, 16 insertions(+)
 create mode 120000 arch/um/include/asm/cmpxchg-x86.h
 create mode 100644 arch/um/include/asm/cmpxchg.h
 create mode 120000 arch/um/include/asm/cmpxchg_32.h
 create mode 120000 arch/um/include/asm/cmpxchg_64.h

On 13/11/2020 11:54, anton.ivanov@cambridgegreys.com wrote:
> From: Anton Ivanov <anton.ivanov@cambridgegreys.com>
>
> UML was falling back to asm-generic cmpxchg which emulates atomic
> behaviour by turning irqs on/off. On UML this means turning
> on/off signals for each cmpxchg which is expensive.
>
> Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com>
> ---
>   arch/um/include/asm/cmpxchg-x86.h |  1 +
>   arch/um/include/asm/cmpxchg.h     | 13 +++++++++++++
>   arch/um/include/asm/cmpxchg_32.h  |  1 +
>   arch/um/include/asm/cmpxchg_64.h  |  1 +
>   4 files changed, 16 insertions(+)
>   create mode 120000 arch/um/include/asm/cmpxchg-x86.h
>   create mode 100644 arch/um/include/asm/cmpxchg.h
>   create mode 120000 arch/um/include/asm/cmpxchg_32.h
>   create mode 120000 arch/um/include/asm/cmpxchg_64.h
>
> diff --git a/arch/um/include/asm/cmpxchg-x86.h b/arch/um/include/asm/cmpxchg-x86.h
> new file mode 120000
> index 000000000000..a5c607edde88
> --- /dev/null
> +++ b/arch/um/include/asm/cmpxchg-x86.h
> @@ -0,0 +1 @@
> +../../../x86/include/asm/cmpxchg.h
> \ No newline at end of file
> diff --git a/arch/um/include/asm/cmpxchg.h b/arch/um/include/asm/cmpxchg.h
> new file mode 100644
> index 000000000000..c9367b37d925
> --- /dev/null
> +++ b/arch/um/include/asm/cmpxchg.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_UM_CMPXCHG_H
> +#define _ASM_UM_CMPXCHG_H
> +
> +#ifdef CONFIG_64BIT
> +#undef CONFIG_X86_32
> +#else
> +#define CONFIG_X86_32 1
> +#endif
> +
> +#include <asm/cmpxchg-x86.h>
> +
> +#endif
> diff --git a/arch/um/include/asm/cmpxchg_32.h b/arch/um/include/asm/cmpxchg_32.h
> new file mode 120000
> index 000000000000..1f360d0a9fa9
> --- /dev/null
> +++ b/arch/um/include/asm/cmpxchg_32.h
> @@ -0,0 +1 @@
> +../../../x86/include/asm/cmpxchg_32.h
> \ No newline at end of file
> diff --git a/arch/um/include/asm/cmpxchg_64.h b/arch/um/include/asm/cmpxchg_64.h
> new file mode 120000
> index 000000000000..bc09ae22b0cb
> --- /dev/null
> +++ b/arch/um/include/asm/cmpxchg_64.h
> @@ -0,0 +1 @@
> +../../../x86/include/asm/cmpxchg_64.h
> \ No newline at end of file

I think that was it. Or to be more exact, I hope that was it.

I went a few times through asm-generic and that looks like all the bits which are worth implementing for a uniprocessor architecture as a replacement for their generic equivalents.

So to recap:

string.h
xor.h
futex.h
cmpxchg.h
atomic.h

Brgds,

On Fri, 2020-11-13 at 13:48 +0000, Anton Ivanov wrote:
> 
> I think that was it. Or to be more exact, I hope that was it.
> 
> I went a few times through asm-generic and that looks like all the
> bits which are worth implementing for a uniprocessor architecture as a
> replacement for their generic equivalents.

It seems that word-at-a-time.h with CONFIG_DCACHE_WORD_ACCESS might 
be worthwhile as well?

Also perhaps bug.h; there are a lot of BUG_ON/WARN_ON and similar
things, and especially the _ONCE part looks better there?

ftrace is probably not worth the effort ...

johannes

On 13/11/2020 15:58, Johannes Berg wrote:
> On Fri, 2020-11-13 at 13:48 +0000, Anton Ivanov wrote:
>> I think that was it. Or to be more exact, I hope that was it.
>>
>> I went a few times through asm-generic and that looks like all the
>> bits which are worth implementing for a uniprocessor architecture as a
>> replacement for their generic equivalents.
> It seems that word-at-a-time.h with CONFIG_DCACHE_WORD_ACCESS might
> be worthwhile as well?

I tried it. It had some references to exception handling which are not 
present in UML so I dropped it for now.

We may get it to work, but it will take some effort. I think it also had 
alternatives in the assembly parts so that means similar problems to 
using x86 memcpy and x86 memmove.

>
> Also perhaps bug.h; there are a lot of BUG_ON/WARN_ON and similar
> things, and especially the _ONCE part looks better there?

There are some advantages there, but the difference between x86 and 
generic does not look to be as drastic as atomics or futex.

We can pull it in.

>
> ftrace is probably not worth the effort ...

Concur.

> johannes
>
>
Brgds,

On Fri, 2020-11-13 at 17:50 +0000, Anton Ivanov wrote:
> On 13/11/2020 15:58, Johannes Berg wrote:
> > On Fri, 2020-11-13 at 13:48 +0000, Anton Ivanov wrote:
> > > I think that was it. Or to be more exact, I hope that was it.
> > > 
> > > I went a few times through asm-generic and that looks like all the
> > > bits which are worth implementing for a uniprocessor architecture as a
> > > replacement for their generic equivalents.
> > It seems that word-at-a-time.h with CONFIG_DCACHE_WORD_ACCESS might
> > be worthwhile as well?
> 
> I tried it. It had some references to exception handling which are not 
> present in UML so I dropped it for now.

Oh, right ... I played with that once for something else and couldn't
figure out how to port it. Oh well.

johannes

On 13/11/2020 20:21, Johannes Berg wrote:
> On Fri, 2020-11-13 at 17:50 +0000, Anton Ivanov wrote:
>> On 13/11/2020 15:58, Johannes Berg wrote:
>>> On Fri, 2020-11-13 at 13:48 +0000, Anton Ivanov wrote:
>>>> I think that was it. Or to be more exact, I hope that was it.
>>>>
>>>> I went a few times through asm-generic and that looks like all the
>>>> bits which are worth implementing for a uniprocessor architecture as a
>>>> replacement for their generic equivalents.
>>> It seems that word-at-a-time.h with CONFIG_DCACHE_WORD_ACCESS might
>>> be worthwhile as well?
>> I tried it. It had some references to exception handling which are not
>> present in UML so I dropped it for now.
> Oh, right ... I played with that once for something else and couldn't
> figure out how to port it. Oh well.

I did only the low hanging fruit this time :)

This one looked like it needs figuring out a porting strategy so I 
skipped it.

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

On 13/11/2020 15:58, Johannes Berg wrote:
> On Fri, 2020-11-13 at 13:48 +0000, Anton Ivanov wrote:
>>
>> I think that was it. Or to be more exact, I hope that was it.
>>
>> I went a few times through asm-generic and that looks like all the
>> bits which are worth implementing for a uniprocessor architecture as a
>> replacement for their generic equivalents.
> 
> It seems that word-at-a-time.h with CONFIG_DCACHE_WORD_ACCESS might
> be worthwhile as well?
> 
> Also perhaps bug.h; there are a lot of BUG_ON/WARN_ON and similar
> things, and especially the _ONCE part looks better there?
> 
> ftrace is probably not worth the effort ...
> 
> johannes
> 
> 
> _______________________________________________
> linux-um mailing list
> linux-um@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
> 

There is one more which makes for a surprisingly big difference - a couple of more % on find /usr -type f -exec cat {} > /dev/null \;

bitops.h

Actually, it is not that surprising, fs and memory which are exercised this way have bitops all over the place.

Patch coming shortly.

I also have a patch to switch to proper cmpxchg in the futex/uaccess, but that has to go in after everything else. If atomics and cmpxchg have not gone in, it actually does more harm than good.

A.