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
next prev parent 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