All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Yugui <wangyugui@e16-tech.com>
To: Wang Yugui <wangyugui@e16-tech.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: dbench throughput(sync, reflink=0|1) on xfs over hardware throughput
Date: Thu, 15 Oct 2020 06:45:36 +0800	[thread overview]
Message-ID: <20201015064535.35D8.409509F4@e16-tech.com> (raw)
In-Reply-To: <20201014124138.7A0E.409509F4@e16-tech.com>

Hi, 

Thanks a lot fo Dave Chinner,

The 'Throughput' of dbench include not only 'write', but also include
'read' in dbench too.

And 'max_latency' include not only 'write', but also include others too.

1)dbench result example1
WriteX        365460     4.474  2279.808
...
Throughput 385.697 MB/sec (sync open)  32 clients  32 procs  max_latency=2279.818 ms

2)dbench result example2
 WriteX        741543     3.521    16.380
 ...
Throughput 779.972 MB/sec (sync open)  48 clients  48 procs  max_latency=11.246 ms


for ext4, with more clients(32->80),  the Throughput of ext4 is over
6Gb/s too.


Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2020/10/15

> Hi,
> 
> For xfs sync performance optimization, there is an option 'osyncisdsync'
> which is removed in 4.0(man xfs)
> 
> the xfs sync performance optimization in linux 5.4.70/5.9.0 is beyond
> 'osyncisdsync'? When multiple write(sync) at the same time, just some of
> them are guaranteed?
> 
> Or deduplication(based on reflink=1) help the sync write?
> and 'mkfs.xfs -m reflink=0' failed to disable it?
> 
> iotop show that 'Actual DISK WRITE:' is NOT over hardware throughput.
> 
> Best Regards
> Wang Yugui (wangyugui@e16-tech.com)
> 2020/10/14
> 
> > Hi,
> > 
> > #any reply, please Cc: wangyugui@e16-tech.com
> > 
> > dbench throughput(sync, reflink=0|1) on xfs over hardware
> > throughput(6Gb/s=750MB/s).
> > 
> > Is this a bug of xfs sync?  or some feature of performance optimization?
> > 
> > we test mkfs.xfs -m reflink=0|1, crc=0|1, still over hardware
> > throughput(6Gb/s=750MB/s).
> > 
> > Disk: TOSHIBA  PX05SMQ040
> > This is a 12Gb/s SAS SSD disk, but connect to 6Gb/s SAS HBA,
> > so it works with 6Gb/s.
> > 
> > dbench -s -t 60 -D /xfs 32
> > #Throughput 884.406 MB/sec (sync open)
> > 
> > 
> > dbench -s -t 60 -D /xfs 1
> > #Throughput 149.172 MB/sec (sync open)
> > 
> > we test the same disk with ext4 filesystem, 
> > the throughput is very close to, but less than the hardware limit.
> > 
> > dbench -s -t 60 -D /ext4 32
> > #Throughput 740.95 MB/sec (sync open)
> > 
> > dbench -s -t 60 -D /ext4 1
> > #Throughput 124.67 MB/sec (sync open)
> > 
> > linux kernel: 5.4.70, 5.9.0
> > 
> > Best Regards
> > Wang Yugui (wangyugui@e16-tech.com)
> > 2020/10/13
> > 
> 



      reply	other threads:[~2020-10-14 22:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-13 15:56 dbench throughput(sync, reflink=0|1) on xfs over hardware throughput Wang Yugui
2020-10-14  4:41 ` Wang Yugui
2020-10-14 22:45   ` Wang Yugui [this message]

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=20201015064535.35D8.409509F4@e16-tech.com \
    --to=wangyugui@e16-tech.com \
    --cc=linux-xfs@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.