Re: [RFC] what to do with IOCB_DSYNC?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 27, 2022 at 11:15 AM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
>
> Hi Ingo,
>
> On 5/27/22, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> >
> > * Jason A. Donenfeld <Jason@xxxxxxxxx> wrote:
> >
> >> On Mon, May 23, 2022 at 10:03:45AM -0600, Jens Axboe wrote:
> >> > clear_user()
> >> > 32 ~96MB/sec
> >> > 64 195MB/sec
> >> > 128        386MB/sec
> >> > 1k 2.7GB/sec
> >> > 4k 7.8GB/sec
> >> > 16k        14.8GB/sec
> >> >
> >> > copy_from_zero_page()
> >> > 32 ~96MB/sec
> >> > 64 193MB/sec
> >> > 128        383MB/sec
> >> > 1k 2.9GB/sec
> >> > 4k 9.8GB/sec
> >> > 16k        21.8GB/sec
> >>
> >> Just FYI, on x86, Samuel Neves proposed some nice clear_user()
> >> performance improvements that were forgotten about:
> >>
> >> https://lore.kernel.org/lkml/20210523180423.108087-1-sneves@xxxxxxxxx/
> >> https://lore.kernel.org/lkml/Yk9yBcj78mpXOOLL@xxxxxxxxx/
> >>
> >> Hoping somebody picks this up at some point...
> >
> > Those ~2x speedup numbers are indeed looking very nice:
> >
> > | After this patch, on a Skylake CPU, these are the
> > | before/after figures:
> > |
> > | $ dd if=/dev/zero of=/dev/null bs=1024k status=progress
> > | 94402248704 bytes (94 GB, 88 GiB) copied, 6 s, 15.7 GB/s
> > |
> > | $ dd if=/dev/zero of=/dev/null bs=1024k status=progress
> > | 446476320768 bytes (446 GB, 416 GiB) copied, 15 s, 29.8 GB/s
> >
> > Patch fell through the cracks & it doesn't apply anymore:
> >
> >   checking file arch/x86/lib/usercopy_64.c
> >   Hunk #2 FAILED at 17.
> >   1 out of 2 hunks FAILED
> >
> > Would be nice to re-send it.
>
> I don't think Samuel is going to do that at this point, so I think
> it's probably best if you do it.

For what it's worth, these are the benchmarks I did at the time
comparing the various code paths (generic loop, rep stosd + stosb, rep
stosd + final loop, rep stosb) for sizes from 0 to 4096 (and then to
32k in larger increments) in the following chips:

 - Atom C2550 - Avoton
 - Xeon E3-1240 v3 - Haswell
 - EPYC 7401P - Zen 1
 - EPYC 7402P - Zen 2
 - Xeon D-1537 - Broadwell
 - Core i7-6700HQ - Skylake
 - Core i7-3770 - Ivy Bridge
 - Xeon Gold 5120 - Skylake-SP

The fields are: bytes, cycles for generic loop, cycles for rep
stosd+stosb, cycles for rep stosd + final loop, cycles for rep stosb.
There are aligned (to cacheline) and unaligned (cacheline+1)
destination buffer numbers, as that seems to be relevant for rep stos
performance.

Make of that what you will; as Jason said, I'm not particularly
interested in reviving this.

Samuel.

> Jason

Attachment: numbers.tar.gz
Description: application/gzip


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux