From: Dave Chinner <david@fromorbit.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linux-xfs@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Dave Chinner <dchinner@redhat.com>
Subject: Re: [rfc] larger batches for crc32c
Date: Fri, 28 Oct 2016 10:16:33 +1100 [thread overview]
Message-ID: <20161027231633.GP14023@dastard> (raw)
In-Reply-To: <20161027214244.GO14023@dastard>
On Fri, Oct 28, 2016 at 08:42:44AM +1100, Dave Chinner wrote:
> On Fri, Oct 28, 2016 at 03:17:47AM +1100, Nicholas Piggin wrote:
> > Hi guys,
> >
> > We're seeing crc32c_le show up in xfs log checksumming on a MySQL benchmark
> > on powerpc. I could reproduce similar overheads with dbench as well.
> >
> > 1.11% mysqld [kernel.vmlinux] [k] __crc32c_le
> > |
> > ---__crc32c_le
> > |
> > --1.11%--chksum_update
> > |
> > --1.11%--crypto_shash_update
> > crc32c
> > xlog_cksum
> > xlog_sync
> > _xfs_log_force_lsn
> > xfs_file_fsync
> > vfs_fsync_range
> > do_fsync
> > sys_fsync
> > system_call
> > 0x17738
> > 0x17704
> > os_file_flush_func
> > fil_flush
>
> 2-3% is the typical CRC CPU overhead I see on metadata/log intensive
> workloads on x86-64, so this doesn't seem unreasonable.
FWIW, I just noticed that qemu is now passing through hardware CRC
feature bits to the guest, so it's now using the hardware
accelerated intel module for CRCs. That "2-3%" I mentioned I used
to see from __crc32c_le is now:
0.35% [kernel] [k] crc32c_pcl_intel_update
And there's about 250MB/s of log+metadata IO being CRC'd in this
workload, so I don't think that the way XFS splits the CRCs into
multiple segments is really all that significant...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-10-27 23:18 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-27 16:17 [rfc] larger batches for crc32c Nicholas Piggin
2016-10-27 18:29 ` Darrick J. Wong
2016-10-28 3:21 ` Nicholas Piggin
2016-10-27 21:42 ` Dave Chinner
2016-10-27 23:16 ` Dave Chinner [this message]
2016-10-28 2:12 ` Nicholas Piggin
2016-10-28 4:29 ` Dave Chinner
2016-10-28 5:02 ` Nicholas Piggin
2016-10-31 3:08 ` Dave Chinner
2016-11-01 3:39 ` Nicholas Piggin
2016-11-01 5:47 ` Dave Chinner
2016-11-02 2:18 ` [rfe]: finobt option separable from crc option? (was [rfc] larger batches for crc32c) L.A. Walsh
2016-11-03 8:29 ` Dave Chinner
2016-11-03 16:04 ` L.A. Walsh
2016-11-03 18:15 ` Eric Sandeen
2016-11-03 23:00 ` Dave Chinner
2016-11-04 6:56 ` L.A. Walsh
2016-11-04 17:37 ` Eric Sandeen
2016-11-04 0:12 ` [rfc] larger batches for crc32c Dave Chinner
2016-11-04 2:28 ` Nicholas Piggin
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=20161027231633.GP14023@dastard \
--to=david@fromorbit.com \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
--cc=npiggin@gmail.com \
/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).