From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756511AbcHVWJs (ORCPT ); Mon, 22 Aug 2016 18:09:48 -0400 Received: from mga09.intel.com ([134.134.136.24]:26520 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754655AbcHVWJr (ORCPT ); Mon, 22 Aug 2016 18:09:47 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,562,1464678000"; d="scan'208";a="869545571" From: "Huang\, Ying" To: Christoph Hellwig Cc: Linus Torvalds , Dave Chinner , LKML , Bob Peterson , Fengguang Wu , LKP , "Huang\, Ying" Subject: Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression References: <20160812060433.GS19025@dastard> <20160812062934.GA17589@yexl-desktop> <20160812085124.GB19354@yexl-desktop> <20160812100208.GA16044@dastard> <20160813003054.GA3101@lst.de> <20160813214825.GA31667@lst.de> <20160813220727.GA4901@wfg-t540p.sh.intel.com> <20160813221507.GA1368@lst.de> <20160813225128.GA6416@wfg-t540p.sh.intel.com> <20160814145053.GA17428@wfg-t540p.sh.intel.com> <20160814161724.GA20274@lst.de> <87vaz1n5ay.fsf@yhuang-mobile.sh.intel.com> Date: Mon, 22 Aug 2016 15:09:44 -0700 In-Reply-To: <87vaz1n5ay.fsf@yhuang-mobile.sh.intel.com> (Ying Huang's message of "Mon, 15 Aug 2016 13:30:29 -0700") Message-ID: <87a8g4ihg7.fsf@yhuang-mobile.sh.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Christoph, "Huang, Ying" writes: > Christoph Hellwig writes: > >> Snipping the long contest: >> >> I think there are three observations here: >> >> (1) removing the mark_page_accessed (which is the only significant >> change in the parent commit) hurts the >> aim7/1BRD_48G-xfs-disk_rr-3000-performance/ivb44 test. >> I'd still rather stick to the filemap version and let the >> VM people sort it out. How do the numbers for this test >> look for XFS vs say ext4 and btrfs? >> (2) lots of additional spinlock contention in the new case. A quick >> check shows that I fat-fingered my rewrite so that we do >> the xfs_inode_set_eofblocks_tag call now for the pure lookup >> case, and pretty much all new cycles come from that. >> (3) Boy, are those xfs_inode_set_eofblocks_tag calls expensive, and >> we're already doing way to many even without my little bug above. >> >> So I've force pushed a new version of the iomap-fixes branch with >> (2) fixed, and also a little patch to xfs_inode_set_eofblocks_tag a >> lot less expensive slotted in before that. Would be good to see >> the numbers with that. > > For the original reported regression, the test result is as follow, > > ========================================================================================= > compiler/cpufreq_governor/debug-setup/disk/fs/kconfig/load/rootfs/tbox_group/test/testcase: > gcc-6/performance/profile/1BRD_48G/xfs/x86_64-rhel/3000/debian-x86_64-2015-02-07.cgz/ivb44/disk_wrt/aim7 > > commit: > f0c6bcba74ac51cb77aadb33ad35cb2dc1ad1506 (parent of first bad commit) > 68a9f5e7007c1afa2cf6830b690a90d0187c0684 (first bad commit) > 99091700659f4df965e138b38b4fa26a29b7eade (base of your fixes branch) > bf4dc6e4ecc2a3d042029319bc8cd4204c185610 (head of your fixes branch) > > f0c6bcba74ac51cb 68a9f5e7007c1afa2cf6830b69 99091700659f4df965e138b38b bf4dc6e4ecc2a3d042029319bc > ---------------- -------------------------- -------------------------- -------------------------- > %stddev %change %stddev %change %stddev %change %stddev > \ | \ | \ | \ > 484435 ± 0% -13.3% 420004 ± 0% -17.0% 402250 ± 0% -15.6% 408998 ± 0% aim7.jobs-per-min It appears the original reported regression hasn't bee resolved by your commit. Could you take a look at the test results and the perf data? Best Regards, Huang, Ying > > And the perf data is as follow, > > "perf-profile.func.cycles-pp.intel_idle": 20.25, > "perf-profile.func.cycles-pp.memset_erms": 11.72, > "perf-profile.func.cycles-pp.copy_user_enhanced_fast_string": 8.37, > "perf-profile.func.cycles-pp.__block_commit_write.isra.21": 3.49, > "perf-profile.func.cycles-pp.block_write_end": 1.77, > "perf-profile.func.cycles-pp.native_queued_spin_lock_slowpath": 1.63, > "perf-profile.func.cycles-pp.unlock_page": 1.58, > "perf-profile.func.cycles-pp.___might_sleep": 1.56, > "perf-profile.func.cycles-pp.__block_write_begin_int": 1.33, > "perf-profile.func.cycles-pp.iov_iter_copy_from_user_atomic": 1.23, > "perf-profile.func.cycles-pp.up_write": 1.21, > "perf-profile.func.cycles-pp.__mark_inode_dirty": 1.18, > "perf-profile.func.cycles-pp.down_write": 1.06, > "perf-profile.func.cycles-pp.mark_buffer_dirty": 0.94, > "perf-profile.func.cycles-pp.generic_write_end": 0.92, > "perf-profile.func.cycles-pp.__radix_tree_lookup": 0.91, > "perf-profile.func.cycles-pp._raw_spin_lock": 0.81, > "perf-profile.func.cycles-pp.entry_SYSCALL_64_fastpath": 0.79, > "perf-profile.func.cycles-pp.__might_sleep": 0.79, > "perf-profile.func.cycles-pp.xfs_file_iomap_begin_delay.isra.9": 0.7, > "perf-profile.func.cycles-pp.__list_del_entry": 0.7, > "perf-profile.func.cycles-pp.vfs_write": 0.69, > "perf-profile.func.cycles-pp.drop_buffers": 0.68, > "perf-profile.func.cycles-pp.xfs_file_write_iter": 0.67, > "perf-profile.func.cycles-pp.rwsem_spin_on_owner": 0.67, > > Best Regards, > Huang, Ying > _______________________________________________ > LKP mailing list > LKP@lists.01.org > https://lists.01.org/mailman/listinfo/lkp From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============7086856269564667686==" MIME-Version: 1.0 From: Huang, Ying To: lkp@lists.01.org Subject: Re: [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression Date: Mon, 22 Aug 2016 15:09:44 -0700 Message-ID: <87a8g4ihg7.fsf@yhuang-mobile.sh.intel.com> In-Reply-To: <87vaz1n5ay.fsf@yhuang-mobile.sh.intel.com> List-Id: --===============7086856269564667686== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, Christoph, "Huang, Ying" writes: > Christoph Hellwig writes: > >> Snipping the long contest: >> >> I think there are three observations here: >> >> (1) removing the mark_page_accessed (which is the only significant >> change in the parent commit) hurts the >> aim7/1BRD_48G-xfs-disk_rr-3000-performance/ivb44 test. >> I'd still rather stick to the filemap version and let the >> VM people sort it out. How do the numbers for this test >> look for XFS vs say ext4 and btrfs? >> (2) lots of additional spinlock contention in the new case. A quick >> check shows that I fat-fingered my rewrite so that we do >> the xfs_inode_set_eofblocks_tag call now for the pure lookup >> case, and pretty much all new cycles come from that. >> (3) Boy, are those xfs_inode_set_eofblocks_tag calls expensive, and >> we're already doing way to many even without my little bug above. >> >> So I've force pushed a new version of the iomap-fixes branch with >> (2) fixed, and also a little patch to xfs_inode_set_eofblocks_tag a >> lot less expensive slotted in before that. Would be good to see >> the numbers with that. > > For the original reported regression, the test result is as follow, > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > compiler/cpufreq_governor/debug-setup/disk/fs/kconfig/load/rootfs/tbox_gr= oup/test/testcase: > gcc-6/performance/profile/1BRD_48G/xfs/x86_64-rhel/3000/debian-x86_64-2= 015-02-07.cgz/ivb44/disk_wrt/aim7 > > commit: = > f0c6bcba74ac51cb77aadb33ad35cb2dc1ad1506 (parent of first bad commit) > 68a9f5e7007c1afa2cf6830b690a90d0187c0684 (first bad commit) > 99091700659f4df965e138b38b4fa26a29b7eade (base of your fixes branch) > bf4dc6e4ecc2a3d042029319bc8cd4204c185610 (head of your fixes branch) > > f0c6bcba74ac51cb 68a9f5e7007c1afa2cf6830b69 99091700659f4df965e138b38b bf= 4dc6e4ecc2a3d042029319bc = > ---------------- -------------------------- -------------------------- --= ------------------------ = > %stddev %change %stddev %change %stddev = %change %stddev > \ | \ | \ = | \ = > 484435 =C2=B1 0% -13.3% 420004 =C2=B1 0% -17.0% 402= 250 =C2=B1 0% -15.6% 408998 =C2=B1 0% aim7.jobs-per-min It appears the original reported regression hasn't bee resolved by your commit. Could you take a look at the test results and the perf data? Best Regards, Huang, Ying > > And the perf data is as follow, > > "perf-profile.func.cycles-pp.intel_idle": 20.25, > "perf-profile.func.cycles-pp.memset_erms": 11.72, > "perf-profile.func.cycles-pp.copy_user_enhanced_fast_string": 8.37, > "perf-profile.func.cycles-pp.__block_commit_write.isra.21": 3.49, > "perf-profile.func.cycles-pp.block_write_end": 1.77, > "perf-profile.func.cycles-pp.native_queued_spin_lock_slowpath": 1.63, > "perf-profile.func.cycles-pp.unlock_page": 1.58, > "perf-profile.func.cycles-pp.___might_sleep": 1.56, > "perf-profile.func.cycles-pp.__block_write_begin_int": 1.33, > "perf-profile.func.cycles-pp.iov_iter_copy_from_user_atomic": 1.23, > "perf-profile.func.cycles-pp.up_write": 1.21, > "perf-profile.func.cycles-pp.__mark_inode_dirty": 1.18, > "perf-profile.func.cycles-pp.down_write": 1.06, > "perf-profile.func.cycles-pp.mark_buffer_dirty": 0.94, > "perf-profile.func.cycles-pp.generic_write_end": 0.92, > "perf-profile.func.cycles-pp.__radix_tree_lookup": 0.91, > "perf-profile.func.cycles-pp._raw_spin_lock": 0.81, > "perf-profile.func.cycles-pp.entry_SYSCALL_64_fastpath": 0.79, > "perf-profile.func.cycles-pp.__might_sleep": 0.79, > "perf-profile.func.cycles-pp.xfs_file_iomap_begin_delay.isra.9": 0.7, > "perf-profile.func.cycles-pp.__list_del_entry": 0.7, > "perf-profile.func.cycles-pp.vfs_write": 0.69, > "perf-profile.func.cycles-pp.drop_buffers": 0.68, > "perf-profile.func.cycles-pp.xfs_file_write_iter": 0.67, > "perf-profile.func.cycles-pp.rwsem_spin_on_owner": 0.67, > > Best Regards, > Huang, Ying > _______________________________________________ > LKP mailing list > LKP(a)lists.01.org > https://lists.01.org/mailman/listinfo/lkp --===============7086856269564667686==--