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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
