public inbox for linux-um@lists.infradead.org
 help / color / mirror / Atom feed
From: Anton Ivanov <anton.ivanov@cambridgegreys.com>
To: Johannes Berg <johannes@sipsolutions.net>, linux-um@lists.infradead.org
Cc: richard@nod.at
Subject: Re: [PATCH v4 2/7] um: enable the use of optimized xor routines in UML
Date: Fri, 11 Dec 2020 21:57:15 +0000	[thread overview]
Message-ID: <d8eb09bd-a8ff-72f1-7ea9-54342935bd60@cambridgegreys.com> (raw)
In-Reply-To: <eaba0159c3925f367e42fd17dcf85b829a703666.camel@sipsolutions.net>

On 11/12/2020 20:07, Johannes Berg wrote:
>> +++ b/arch/um/include/asm/fpu/api.h
>> @@ -0,0 +1,14 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +#ifndef _ASM_UM_FPU_API_H
>> +#define _ASM_UM_FPU_API_H
>> +
>> +/* Copyright (c) 2020 Cambridge Greys Ltd
>> + * Copyright (c) 2020 Red Hat Inc.
>> + * A set of "dummy" defines to allow the direct inclusion
>> + * of x86 optimized copy, xor, etc routines into the
>> + * UML code tree. */
>> +
>> +#define kernel_fpu_begin() (void)0
>> +#define kernel_fpu_end() (void)0
> I think I would prefer those to be static inlines, but YMMV.
>
> johannes
>
>> diff --git a/arch/um/include/asm/xor-x86.h b/arch/um/include/asm/xor-x86.h
>> new file mode 120000
>> index 000000000000..beff7de6890d
>> --- /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.

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.

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

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

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.

A.

>
>> --- a/arch/um/include/asm/xor.h
>> +++ b/arch/um/include/asm/xor.h
>> @@ -1,7 +1,22 @@
>>   /* SPDX-License-Identifier: GPL-2.0 */
>> -#include <asm-generic/xor.h>
>> +#ifndef _ASM_UM_XOR_H
>> +#define _ASM_UM_XOR_H
>> +
>> +#ifdef CONFIG_64BIT
>> +#undef CONFIG_X86_32
>> +#else
>> +#define CONFIG_X86_32 1
>> +#endif
>> +
>> +#include <asm/cpufeature.h>
>> +#include <asm/xor-x86.h>
> and thus this could just be
>
> #include_next <asm/xor.h>
>
> without the symlink?
>
>> diff --git a/arch/um/include/asm/xor_32.h b/arch/um/include/asm/xor_32.h
>> new file mode 120000
>> index 000000000000..8a0894e996d7
>> --- /dev/null
>> +++ b/arch/um/include/asm/xor_32.h
>
> And the others don't exist in um anyway, so probably aren't needed?
>
> But maybe I'm confused about the include path, I didn't double-check
> now.
>
> johannes
>
>
>
> _______________________________________________
> 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


  reply	other threads:[~2020-12-11 21:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-11 17:45 Amended and retested for 32 bit "borrow ops" series anton.ivanov
2020-12-11 17:45 ` [PATCH v4 1/7] um: allow the use of glibc functions instead of builtins anton.ivanov
2020-12-11 20:03   ` Johannes Berg
2020-12-11 17:45 ` [PATCH v4 2/7] um: enable the use of optimized xor routines in UML anton.ivanov
2020-12-11 20:07   ` Johannes Berg
2020-12-11 21:57     ` Anton Ivanov [this message]
2020-12-11 22:00       ` Johannes Berg
2020-12-11 22:40         ` Anton Ivanov
2020-12-14  9:07         ` Anton Ivanov
2020-12-14  9:12           ` Johannes Berg
2020-12-14  9:36             ` Anton Ivanov
2020-12-11 17:45 ` [PATCH v4 3/7] um: "borrow" atomics from x86 architecture anton.ivanov
2020-12-11 20:08   ` Johannes Berg
2020-12-11 21:31     ` Anton Ivanov
2020-12-11 17:45 ` [PATCH v4 4/7] um: add a UML specific futex implementation anton.ivanov
2020-12-11 20:10   ` Johannes Berg
2020-12-11 17:45 ` [PATCH v4 5/7] um: "borrow" cmpxchg from x86 tree in UML anton.ivanov
2020-12-11 17:45 ` [PATCH v4 6/7] um: swithch futex ops to cmpxchg anton.ivanov
2020-12-11 20:12   ` Johannes Berg
2020-12-11 21:33     ` Anton Ivanov
2020-12-11 17:45 ` [PATCH v4 7/7] um: borrow bitops from the x86 tree anton.ivanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d8eb09bd-a8ff-72f1-7ea9-54342935bd60@cambridgegreys.com \
    --to=anton.ivanov@cambridgegreys.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-um@lists.infradead.org \
    --cc=richard@nod.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox