From: David Laight <David.Laight@ACULAB.COM>
To: 'Vineet Gupta' <vgupta@kernel.org>,
Matteo Croce <mcroce@linux.microsoft.com>,
Guo Ren <guoren@kernel.org>
Cc: linux-riscv <linux-riscv@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Atish Patra <atish.patra@wdc.com>,
"Emil Renner Berthing" <kernel@esmil.dk>,
Akira Tsukamoto <akira.tsukamoto@gmail.com>,
Drew Fustini <drew@beagleboard.org>,
Bin Meng <bmeng.cn@gmail.com>, Christoph Hellwig <hch@lst.de>,
Philipp Tomsich <philipp.tomsich@vrull.eu>
Subject: RE: [PATCH v5 1/3] riscv: optimized memcpy
Date: Fri, 1 Oct 2021 08:06:13 +0000 [thread overview]
Message-ID: <63ab9e73cb58404c99e271b11b2b5bf5@AcuMS.aculab.com> (raw)
In-Reply-To: <a9ce9ea2-9e5d-0e56-d980-5dedd087f62d@kernel.org>
...
> BTW off topic (but relevant to this patchset), I strongly feel that
> routines like memset/memcpy are better coded in assembly for really
> water tight instruction scheduling and ease of further optimizing (e.g.
> use of CMO.zero etc as experimented by Philipp). What is blocking you
> from optimizing the asm version ? You are leaving the fate of these
> critical routines in the hand of compiler - this can lead to performance
> shenanigans on a big gcc upgrade.
You also need to worry about the cost of short transfers.
A few cycles there could have a much bigger difference
that something that speeds up long transfers.
Short ones are likely to be fairly common.
I doubt the loop unrolling optimisation in gcc is actually
any good for loops that might be done a few times.
Fortunately the kernel doesn't get 'hit by' gcc unrolling
loops into the AVX instructions.
The setup costs for that (and I-cache footprint) are horrid.
Although I suspect it is that optimisation that 'broke'
code that used misaligned pointers on overlapping data.
It is a general problem with the 'one size fits all' memcpy().
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2021-10-01 8:06 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-29 17:22 [PATCH v5 0/3] riscv: optimized mem* functions Matteo Croce
2021-09-29 17:22 ` [PATCH v5 1/3] riscv: optimized memcpy Matteo Croce
2021-09-30 1:24 ` Guo Ren
2021-09-30 1:36 ` Matteo Croce
2021-09-30 19:43 ` Vineet Gupta
2021-10-01 8:06 ` David Laight [this message]
2021-10-01 11:23 ` Pavel Machek
2021-10-02 17:20 ` Matteo Croce
2021-09-29 17:22 ` [PATCH v5 2/3] riscv: optimized memmove Matteo Croce
2021-09-29 17:22 ` [PATCH v5 3/3] riscv: optimized memset Matteo Croce
2021-11-25 10:56 ` Ley Foon Tan
2021-12-06 20:37 ` Emil Renner Berthing
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=63ab9e73cb58404c99e271b11b2b5bf5@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=akira.tsukamoto@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@wdc.com \
--cc=bmeng.cn@gmail.com \
--cc=drew@beagleboard.org \
--cc=guoren@kernel.org \
--cc=hch@lst.de \
--cc=kernel@esmil.dk \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mcroce@linux.microsoft.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=philipp.tomsich@vrull.eu \
--cc=vgupta@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;
as well as URLs for NNTP newsgroup(s).