From: David Laight <David.Laight@ACULAB.COM>
To: 'Hugh Dickins' <hughd@google.com>, Borislav Petkov <bp@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>
Subject: RE: x86: should clear_user() have alternatives?
Date: Tue, 8 Feb 2022 11:45:38 +0000 [thread overview]
Message-ID: <9fc41af45fcb40e3ae607eb4f52d7ef9@AcuMS.aculab.com> (raw)
In-Reply-To: <2f5ca5e4-e250-a41c-11fb-a7f4ebc7e1c9@google.com>
From: Hugh Dickins
> Sent: 08 February 2022 05:46
>
> I've noticed that clear_user() is slower than it need be:
>
> dd if=/dev/zero of=/dev/null bs=1M count=1M
> 1099511627776 bytes (1.1 TB) copied, 45.9641 s, 23.9 GB/s
> whereas with the hacked patch below
> 1099511627776 bytes (1.1 TB) copied, 33.4 s, 32.9 GB/s
>
> That was on some Intel machine: IIRC an AMD went faster.
>
> It's because clear_user() lacks alternatives, and uses a
> nowadays suboptimal implementation; whereas clear_page()
> and copy_user() do support alternatives.
>
...
> +SYM_FUNC_START(__clear_user)
> + ASM_STAC
> + movl %esi,%ecx
> + xorq %rax,%rax
> +1: rep stosb
> +2: movl %ecx,%eax
> + ASM_CLAC
> + ret
You only want to even consider than version for long copies
(and possibly only for aligned ones).
The existing code (I've not quoted) does look sub-optimal though.
It should be easy to obtain a write every clock.
But I suspect the loop is too long.
The code gcc generates might even be better!
Note that for copies longer than 8 bytes 'odd' lengths can
be handled by a single misaligned write to the end of the buffer.
No need for a byte copy loop.
I've not experimented with misaligned writes - they might take two clocks.
So it might be worth aligning them - but they may not happen often
enough for it to be an overall gain.
Misaligned reads usually don't make any difference.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2022-02-08 11:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 5:45 x86: should clear_user() have alternatives? Hugh Dickins
2022-02-08 11:45 ` David Laight [this message]
2022-02-08 12:52 ` Borislav Petkov
2022-02-08 23:36 ` David Laight
2022-02-09 6:18 ` Hugh Dickins
2022-04-07 23:21 ` Jason A. Donenfeld
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=9fc41af45fcb40e3ae607eb4f52d7ef9@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=bp@suse.de \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
/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