From: "Huang\, Ying" <ying.huang@linux.intel.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Dave Chinner <david@fromorbit.com>,
LKML <linux-kernel@vger.kernel.org>,
Bob Peterson <rpeterso@redhat.com>,
Fengguang Wu <fengguang.wu@intel.com>, LKP <lkp@01.org>, "Huang\,
Ying" <ying.huang@intel.com>
Subject: Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression
Date: Mon, 26 Sep 2016 14:25:11 +0800 [thread overview]
Message-ID: <87k2dzi3eg.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <87a8g4ihg7.fsf@yhuang-mobile.sh.intel.com> (Ying Huang's message of "Mon, 22 Aug 2016 15:09:44 -0700")
Hi, Christoph,
"Huang, Ying" <ying.huang@intel.com> writes:
> Hi, Christoph,
>
> "Huang, Ying" <ying.huang@intel.com> writes:
>
>> Christoph Hellwig <hch@lst.de> 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?
Any update to this regression?
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
next prev parent reply other threads:[~2016-09-26 6:25 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-09 14:33 [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression kernel test robot
2016-08-10 18:24 ` Linus Torvalds
2016-08-10 23:08 ` Dave Chinner
2016-08-10 23:51 ` Linus Torvalds
2016-08-10 23:58 ` [LKP] " Huang, Ying
2016-08-11 0:11 ` Huang, Ying
2016-08-11 0:23 ` Linus Torvalds
2016-08-11 0:33 ` Huang, Ying
2016-08-11 1:00 ` Linus Torvalds
2016-08-11 4:46 ` Dave Chinner
2016-08-15 17:22 ` Huang, Ying
2016-08-16 0:08 ` Dave Chinner
2016-08-11 15:57 ` Christoph Hellwig
2016-08-11 16:55 ` Linus Torvalds
2016-08-11 17:51 ` Huang, Ying
2016-08-11 19:51 ` Linus Torvalds
2016-08-11 20:00 ` Christoph Hellwig
2016-08-11 20:35 ` Linus Torvalds
2016-08-11 22:16 ` Al Viro
2016-08-11 22:30 ` Linus Torvalds
2016-08-11 21:16 ` Huang, Ying
2016-08-11 21:40 ` Linus Torvalds
2016-08-11 22:08 ` Christoph Hellwig
2016-08-12 0:54 ` Dave Chinner
2016-08-12 2:23 ` Dave Chinner
2016-08-12 2:32 ` Linus Torvalds
2016-08-12 2:52 ` Christoph Hellwig
2016-08-12 3:20 ` Linus Torvalds
2016-08-12 4:16 ` Dave Chinner
2016-08-12 5:02 ` Linus Torvalds
2016-08-12 6:04 ` Dave Chinner
2016-08-12 6:29 ` Ye Xiaolong
2016-08-12 8:51 ` Ye Xiaolong
2016-08-12 10:02 ` Dave Chinner
2016-08-12 10:43 ` Fengguang Wu
2016-08-13 0:30 ` [LKP] [lkp] " Christoph Hellwig
2016-08-13 21:48 ` Christoph Hellwig
2016-08-13 22:07 ` Fengguang Wu
2016-08-13 22:15 ` Christoph Hellwig
2016-08-13 22:51 ` Fengguang Wu
2016-08-14 14:50 ` Fengguang Wu
2016-08-14 16:17 ` Christoph Hellwig
2016-08-14 23:46 ` Dave Chinner
2016-08-14 23:57 ` Fengguang Wu
2016-08-15 14:14 ` Fengguang Wu
2016-08-15 21:22 ` Dave Chinner
2016-08-16 12:20 ` Fengguang Wu
2016-08-15 20:30 ` Huang, Ying
2016-08-22 22:09 ` Huang, Ying
2016-09-26 6:25 ` Huang, Ying [this message]
2016-09-26 14:55 ` Christoph Hellwig
2016-09-27 0:52 ` Huang, Ying
2016-08-16 13:25 ` Fengguang Wu
2016-08-13 23:32 ` Dave Chinner
2016-08-12 2:27 ` Linus Torvalds
2016-08-12 3:56 ` Dave Chinner
2016-08-12 18:03 ` Linus Torvalds
2016-08-13 23:58 ` Fengguang Wu
2016-08-15 0:48 ` Dave Chinner
2016-08-15 1:37 ` Linus Torvalds
2016-08-15 2:28 ` Dave Chinner
2016-08-15 2:53 ` Linus Torvalds
2016-08-15 5:00 ` Dave Chinner
[not found] ` <CA+55aFwva2Xffai+Eqv1Jn_NGryk3YJ2i5JoHOQnbQv6qVPAsw@mail.gmail.com>
[not found] ` <CA+55aFy14nUnJQ_GdF=j8Fa9xiH70c6fY2G3q5HQ01+8z1z3qQ@mail.gmail.com>
[not found] ` <CA+55aFxp+rLehC8c157uRbH459wUC1rRPfCVgvmcq5BrG9gkyg@mail.gmail.com>
2016-08-15 22:22 ` Dave Chinner
2016-08-15 22:42 ` Dave Chinner
2016-08-15 23:20 ` Linus Torvalds
2016-08-15 23:48 ` Linus Torvalds
2016-08-16 0:44 ` Dave Chinner
2016-08-16 15:05 ` Mel Gorman
2016-08-16 17:47 ` Linus Torvalds
2016-08-17 15:48 ` Michal Hocko
2016-08-17 16:42 ` Michal Hocko
2016-08-17 15:49 ` Mel Gorman
2016-08-18 0:45 ` Mel Gorman
2016-08-18 7:11 ` Dave Chinner
2016-08-18 13:24 ` Mel Gorman
2016-08-18 17:55 ` Linus Torvalds
2016-08-18 21:19 ` Dave Chinner
2016-08-18 22:25 ` Linus Torvalds
2016-08-19 9:00 ` Michal Hocko
2016-08-19 10:49 ` Mel Gorman
2016-08-19 23:48 ` Dave Chinner
2016-08-20 1:08 ` Linus Torvalds
2016-08-20 12:16 ` Mel Gorman
2016-08-19 15:08 ` Mel Gorman
2016-09-01 23:32 ` Dave Chinner
2016-09-06 15:37 ` Mel Gorman
2016-09-06 15:52 ` Huang, Ying
2016-08-24 15:40 ` Huang, Ying
2016-08-25 9:37 ` Mel Gorman
2016-08-18 2:44 ` Dave Chinner
2016-08-16 0:15 ` Linus Torvalds
2016-08-16 0:38 ` Dave Chinner
2016-08-16 0:50 ` Linus Torvalds
2016-08-16 0:19 ` Dave Chinner
2016-08-16 1:51 ` Linus Torvalds
2016-08-16 22:02 ` Dave Chinner
2016-08-16 23:23 ` Linus Torvalds
2016-08-15 23:01 ` Linus Torvalds
2016-08-16 0:17 ` Dave Chinner
2016-08-16 0:45 ` Linus Torvalds
2016-08-15 5:03 ` Ingo Molnar
2016-08-17 16:24 ` Peter Zijlstra
2016-08-15 12:58 ` Fengguang Wu
2016-08-11 1:16 ` Dave Chinner
2016-08-11 1:32 ` Dave Chinner
2016-08-11 2:36 ` Ye Xiaolong
2016-08-11 3:05 ` Dave Chinner
2016-08-12 1:26 ` Dave Chinner
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=87k2dzi3eg.fsf@yhuang-dev.intel.com \
--to=ying.huang@linux.intel.com \
--cc=david@fromorbit.com \
--cc=fengguang.wu@intel.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=rpeterso@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=ying.huang@intel.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