On Wed, Jun 8, 2022 at 10:39 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Jun 08, 2022 at 09:28:18PM +0200, Sedat Dilek wrote:
>
> > I have pulled this on top of Linux v5.19-rc1... plus assorted patches
> > to fix issues with LLVM/Clang version 14.
> > No (new) warnings in my build-log.
> > Boots fine on bare metal on my Debian/unstable AMD64 system.
> >
> > Any hints for testing - to see improvements?
>
> Profiling, basically... A somewhat artificial microbenchmark would be
> to remove read_null()/write_null()/read_zero()/write_zero(), along with
> the corresponding .read and .write initializers in drivers/char/mem.c
> and see how dd to/from /dev/zero and friends behaves. On the mainline
> it gives a noticable regression, due to overhead in new_sync_{read,write}().
> With this series it should get better; pipe reads/writes also should see
> reduction of overhead.
>
> There'd been a thread regarding /dev/random stuff; look for
> "random: convert to using iters" and things nearby...
Hmm, I did not find it...
I bookmarked Ingo's reply on Boris x86-usercopy patch.
There is a vague description without (for me at least) concrete instructions.
> So Mel gave me the idea to simply measure how fast the function becomes.
> ...
My SandyBridge-CPU has no FSRM feature, so I'm unsure if I really
benefit from your changes.
My test-cases:
1. LC_ALL=C dd if=/dev/zero of=/dev/null bs=1M count=1M status=progress
2. perf bench mem memcpy (with Debian's perf v5.18 and a selfmade v5.19-rc1)
First test-case shows no measurable/noticable differences.
The 2nd one I ran for the first time with your changes and did not
compare with a kernel without them.
Link to the 2nd test-case and comments see [1].
In a later version you may add some notes/comments about benchmarking.
"Numbers talk - bullshit walks." Linus T.
-Sedat-
[1] https://lore.kernel.org/all/YpCxt31TKxV5zS3l@xxxxxxxxx/
