* [btrfs] 4c468fd7485: +7.8% blogbench.write_score, -5.1% turbostat.Pkg_W
@ 2014-08-16 7:52 ` Fengguang Wu
0 siblings, 0 replies; 16+ messages in thread
From: Fengguang Wu @ 2014-08-16 7:52 UTC (permalink / raw)
To: Chris Mason; +Cc: Dave Hansen, LKML, lkp, linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 6308 bytes --]
Hi Chris,
FYI, we noticed increased performance and reduced power consumption on
commit 4c468fd74859d901c0b78b42bef189295e00d74f ("btrfs: disable strict file flushes for renames and truncates")
test case: lkp-sb02/blogbench/1HDD-btrfs
0954d74f8f37a47 4c468fd74859d901c0b78b42b
--------------- -------------------------
1094 ± 1% +7.8% 1180 ± 2% TOTAL blogbench.write_score
1396 ±19% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.active_objs
1497 ±17% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.num_objs
426 ±45% -100.0% 0 ± 0% TOTAL proc-vmstat.nr_vmscan_write
1.02 ±38% +193.1% 2.99 ±37% TOTAL turbostat.%pc6
0.12 ±48% +113.8% 0.25 ±29% TOTAL turbostat.%pc3
0.38 ±18% +117.7% 0.84 ±34% TOTAL turbostat.%pc2
19377 ±14% -50.9% 9520 ±20% TOTAL proc-vmstat.workingset_refault
44 ±41% +68.8% 75 ±28% TOTAL cpuidle.POLL.usage
31549 ± 1% +95.7% 61732 ± 1% TOTAL softirqs.BLOCK
4547 ±10% -38.3% 2804 ± 9% TOTAL slabinfo.btrfs_ordered_extent.active_objs
4628 ±10% -37.1% 2913 ± 9% TOTAL slabinfo.btrfs_ordered_extent.num_objs
17597 ± 8% -30.2% 12291 ±14% TOTAL proc-vmstat.nr_writeback
70335 ± 8% -30.1% 49174 ±14% TOTAL meminfo.Writeback
3606 ± 6% -29.1% 2556 ±10% TOTAL slabinfo.mnt_cache.active_objs
14763 ±12% -29.9% 10350 ± 8% TOTAL proc-vmstat.nr_dirty
3766 ± 5% -27.8% 2720 ±10% TOTAL slabinfo.mnt_cache.num_objs
3509 ± 6% -28.5% 2510 ±11% TOTAL slabinfo.kmalloc-4096.active_objs
59201 ±11% -30.1% 41396 ± 8% TOTAL meminfo.Dirty
479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.num_slabs
479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.active_slabs
3636 ± 6% -26.6% 2669 ±10% TOTAL slabinfo.kmalloc-4096.num_objs
6040 ± 8% -28.6% 4314 ± 6% TOTAL slabinfo.kmalloc-96.num_objs
5358 ± 5% -25.1% 4011 ± 7% TOTAL slabinfo.kmalloc-96.active_objs
757208 ± 4% -22.1% 589874 ± 4% TOTAL meminfo.MemFree
189508 ± 4% -22.2% 147518 ± 4% TOTAL proc-vmstat.nr_free_pages
762781 ± 4% -21.1% 601525 ± 4% TOTAL vmstat.memory.free
10491 ± 2% -16.8% 8725 ± 2% TOTAL slabinfo.kmalloc-64.num_objs
2513 ± 4% +16.3% 2923 ± 4% TOTAL slabinfo.kmalloc-128.active_objs
9768 ± 3% -15.1% 8298 ± 1% TOTAL slabinfo.kmalloc-64.active_objs
2627 ± 4% +14.0% 2995 ± 4% TOTAL slabinfo.kmalloc-128.num_objs
96242 ± 2% +15.5% 111120 ± 2% TOTAL slabinfo.btrfs_path.active_objs
3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.num_slabs
3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.active_slabs
96580 ± 2% +15.1% 111132 ± 2% TOTAL slabinfo.btrfs_path.num_objs
2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.num_slabs
2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.active_slabs
106133 ± 2% +13.5% 120434 ± 1% TOTAL slabinfo.btrfs_extent_state.num_objs
104326 ± 2% +12.3% 117189 ± 1% TOTAL slabinfo.btrfs_extent_state.active_objs
110759 ± 2% +13.4% 125640 ± 2% TOTAL slabinfo.btrfs_inode.active_objs
110759 ± 2% +13.4% 125642 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_objs
4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_slabs
4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_slabs
110797 ± 2% +13.4% 125663 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_objs
110815 ± 2% +13.4% 125669 ± 2% TOTAL slabinfo.btrfs_inode.num_objs
6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.num_slabs
6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.active_slabs
5607 ± 3% -11.0% 4991 ± 3% TOTAL slabinfo.kmalloc-256.active_objs
6077 ± 2% -9.9% 5476 ± 3% TOTAL slabinfo.kmalloc-256.num_objs
11153 ± 1% -7.7% 10295 ± 2% TOTAL proc-vmstat.nr_slab_unreclaimable
547824 ± 3% +16.5% 638368 ± 8% TOTAL meminfo.Inactive(file)
112124 ± 2% +11.6% 125105 ± 2% TOTAL slabinfo.radix_tree_node.active_objs
112169 ± 2% +11.6% 125134 ± 2% TOTAL slabinfo.radix_tree_node.num_objs
4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.num_slabs
4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.active_slabs
551119 ± 3% +16.4% 641663 ± 8% TOTAL meminfo.Inactive
285596 ± 2% +11.4% 318160 ± 2% TOTAL meminfo.SReclaimable
156 ± 3% +118.0% 340 ± 2% TOTAL iostat.sda.w/s
282 ± 3% -43.2% 160 ± 3% TOTAL iostat.sda.avgrq-sz
1.45 ±12% -28.9% 1.03 ±18% TOTAL iostat.sda.rrqm/s
633 ± 2% -26.5% 465 ± 2% TOTAL iostat.sda.wrqm/s
154423 ± 5% +17.4% 181309 ± 3% TOTAL time.voluntary_context_switches
536 ± 5% -11.5% 474 ± 9% TOTAL iostat.sda.await
102.71 ± 5% +10.4% 113.36 ± 6% TOTAL iostat.sda.avgqu-sz
20842 ± 2% -6.5% 19493 ± 2% TOTAL iostat.sda.wkB/s
20856 ± 2% -6.4% 19525 ± 2% TOTAL vmstat.io.bo
75.48 ± 4% -6.9% 70.27 ± 5% TOTAL turbostat.%c0
285 ± 4% -6.6% 266 ± 5% TOTAL time.percent_of_cpu_this_job_got
34.58 ± 2% -5.5% 32.68 ± 3% TOTAL turbostat.Cor_W
39.86 ± 2% -5.1% 37.82 ± 3% TOTAL turbostat.Pkg_W
5805 ± 1% -4.3% 5558 ± 3% TOTAL vmstat.system.in
10069454 ± 1% +6.3% 10699830 ± 1% TOTAL time.file_system_outputs
Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.
Thanks,
Fengguang
[-- Attachment #2: reproduce --]
[-- Type: text/plain, Size: 374 bytes --]
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
mkfs -t btrfs /dev/sda2
mount -t btrfs /dev/sda2 /fs/sda2
./blogbench -d /fs/sda2
^ permalink raw reply [flat|nested] 16+ messages in thread* [btrfs] 4c468fd7485: +7.8% blogbench.write_score, -5.1% turbostat.Pkg_W @ 2014-08-16 7:52 ` Fengguang Wu 0 siblings, 0 replies; 16+ messages in thread From: Fengguang Wu @ 2014-08-16 7:52 UTC (permalink / raw) To: lkp [-- Attachment #1: Type: text/plain, Size: 6399 bytes --] Hi Chris, FYI, we noticed increased performance and reduced power consumption on commit 4c468fd74859d901c0b78b42bef189295e00d74f ("btrfs: disable strict file flushes for renames and truncates") test case: lkp-sb02/blogbench/1HDD-btrfs 0954d74f8f37a47 4c468fd74859d901c0b78b42b --------------- ------------------------- 1094 ± 1% +7.8% 1180 ± 2% TOTAL blogbench.write_score 1396 ±19% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.active_objs 1497 ±17% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.num_objs 426 ±45% -100.0% 0 ± 0% TOTAL proc-vmstat.nr_vmscan_write 1.02 ±38% +193.1% 2.99 ±37% TOTAL turbostat.%pc6 0.12 ±48% +113.8% 0.25 ±29% TOTAL turbostat.%pc3 0.38 ±18% +117.7% 0.84 ±34% TOTAL turbostat.%pc2 19377 ±14% -50.9% 9520 ±20% TOTAL proc-vmstat.workingset_refault 44 ±41% +68.8% 75 ±28% TOTAL cpuidle.POLL.usage 31549 ± 1% +95.7% 61732 ± 1% TOTAL softirqs.BLOCK 4547 ±10% -38.3% 2804 ± 9% TOTAL slabinfo.btrfs_ordered_extent.active_objs 4628 ±10% -37.1% 2913 ± 9% TOTAL slabinfo.btrfs_ordered_extent.num_objs 17597 ± 8% -30.2% 12291 ±14% TOTAL proc-vmstat.nr_writeback 70335 ± 8% -30.1% 49174 ±14% TOTAL meminfo.Writeback 3606 ± 6% -29.1% 2556 ±10% TOTAL slabinfo.mnt_cache.active_objs 14763 ±12% -29.9% 10350 ± 8% TOTAL proc-vmstat.nr_dirty 3766 ± 5% -27.8% 2720 ±10% TOTAL slabinfo.mnt_cache.num_objs 3509 ± 6% -28.5% 2510 ±11% TOTAL slabinfo.kmalloc-4096.active_objs 59201 ±11% -30.1% 41396 ± 8% TOTAL meminfo.Dirty 479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.num_slabs 479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.active_slabs 3636 ± 6% -26.6% 2669 ±10% TOTAL slabinfo.kmalloc-4096.num_objs 6040 ± 8% -28.6% 4314 ± 6% TOTAL slabinfo.kmalloc-96.num_objs 5358 ± 5% -25.1% 4011 ± 7% TOTAL slabinfo.kmalloc-96.active_objs 757208 ± 4% -22.1% 589874 ± 4% TOTAL meminfo.MemFree 189508 ± 4% -22.2% 147518 ± 4% TOTAL proc-vmstat.nr_free_pages 762781 ± 4% -21.1% 601525 ± 4% TOTAL vmstat.memory.free 10491 ± 2% -16.8% 8725 ± 2% TOTAL slabinfo.kmalloc-64.num_objs 2513 ± 4% +16.3% 2923 ± 4% TOTAL slabinfo.kmalloc-128.active_objs 9768 ± 3% -15.1% 8298 ± 1% TOTAL slabinfo.kmalloc-64.active_objs 2627 ± 4% +14.0% 2995 ± 4% TOTAL slabinfo.kmalloc-128.num_objs 96242 ± 2% +15.5% 111120 ± 2% TOTAL slabinfo.btrfs_path.active_objs 3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.num_slabs 3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.active_slabs 96580 ± 2% +15.1% 111132 ± 2% TOTAL slabinfo.btrfs_path.num_objs 2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.num_slabs 2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.active_slabs 106133 ± 2% +13.5% 120434 ± 1% TOTAL slabinfo.btrfs_extent_state.num_objs 104326 ± 2% +12.3% 117189 ± 1% TOTAL slabinfo.btrfs_extent_state.active_objs 110759 ± 2% +13.4% 125640 ± 2% TOTAL slabinfo.btrfs_inode.active_objs 110759 ± 2% +13.4% 125642 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_objs 4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_slabs 4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_slabs 110797 ± 2% +13.4% 125663 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_objs 110815 ± 2% +13.4% 125669 ± 2% TOTAL slabinfo.btrfs_inode.num_objs 6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.num_slabs 6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.active_slabs 5607 ± 3% -11.0% 4991 ± 3% TOTAL slabinfo.kmalloc-256.active_objs 6077 ± 2% -9.9% 5476 ± 3% TOTAL slabinfo.kmalloc-256.num_objs 11153 ± 1% -7.7% 10295 ± 2% TOTAL proc-vmstat.nr_slab_unreclaimable 547824 ± 3% +16.5% 638368 ± 8% TOTAL meminfo.Inactive(file) 112124 ± 2% +11.6% 125105 ± 2% TOTAL slabinfo.radix_tree_node.active_objs 112169 ± 2% +11.6% 125134 ± 2% TOTAL slabinfo.radix_tree_node.num_objs 4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.num_slabs 4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.active_slabs 551119 ± 3% +16.4% 641663 ± 8% TOTAL meminfo.Inactive 285596 ± 2% +11.4% 318160 ± 2% TOTAL meminfo.SReclaimable 156 ± 3% +118.0% 340 ± 2% TOTAL iostat.sda.w/s 282 ± 3% -43.2% 160 ± 3% TOTAL iostat.sda.avgrq-sz 1.45 ±12% -28.9% 1.03 ±18% TOTAL iostat.sda.rrqm/s 633 ± 2% -26.5% 465 ± 2% TOTAL iostat.sda.wrqm/s 154423 ± 5% +17.4% 181309 ± 3% TOTAL time.voluntary_context_switches 536 ± 5% -11.5% 474 ± 9% TOTAL iostat.sda.await 102.71 ± 5% +10.4% 113.36 ± 6% TOTAL iostat.sda.avgqu-sz 20842 ± 2% -6.5% 19493 ± 2% TOTAL iostat.sda.wkB/s 20856 ± 2% -6.4% 19525 ± 2% TOTAL vmstat.io.bo 75.48 ± 4% -6.9% 70.27 ± 5% TOTAL turbostat.%c0 285 ± 4% -6.6% 266 ± 5% TOTAL time.percent_of_cpu_this_job_got 34.58 ± 2% -5.5% 32.68 ± 3% TOTAL turbostat.Cor_W 39.86 ± 2% -5.1% 37.82 ± 3% TOTAL turbostat.Pkg_W 5805 ± 1% -4.3% 5558 ± 3% TOTAL vmstat.system.in 10069454 ± 1% +6.3% 10699830 ± 1% TOTAL time.file_system_outputs Disclaimer: Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance. Thanks, Fengguang [-- Attachment #2: reproduce.ksh --] [-- Type: text/plain, Size: 374 bytes --] echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor mkfs -t btrfs /dev/sda2 mount -t btrfs /dev/sda2 /fs/sda2 ./blogbench -d /fs/sda2 ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <CAKHchJwQcH326Z8otiaXtKoKs6fH9s+e9BqJDi=H1bWKiuybAw@mail.gmail.com>]
* Re: [btrfs] 4c468fd7485: +7.8% blogbench.write_score, -5.1% turbostat.Pkg_W [not found] ` <CAKHchJwQcH326Z8otiaXtKoKs6fH9s+e9BqJDi=H1bWKiuybAw@mail.gmail.com> @ 2014-08-16 13:10 ` Fengguang Wu 0 siblings, 0 replies; 16+ messages in thread From: Fengguang Wu @ 2014-08-16 13:10 UTC (permalink / raw) To: Abhay Sachan; +Cc: Chris Mason, Dave Hansen, LKML, lkp, linux-btrfs Hi Abhay, On Sat, Aug 16, 2014 at 05:30:35PM +0530, Abhay Sachan wrote: > Hi Fengguag, > Sorry for the out of topic question, but what benchmark is this? > I have heard about blogbench, but it doesn't give output in this format AFAIK. It is blogbench run in the lkp-tests framework. https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/ It will collect various system stats when blogbench runs. Then it presents you the collected blogbench stats together with slabinfo, meminfo, proc-vmstat, turbostat, softirqs etc. stats. The basic steps to reproduce this report are $ split-job jobs/blogbench.yaml jobs/blogbench.yaml => ./blogbench-1HDD-ext4.yaml jobs/blogbench.yaml => ./blogbench-1HDD-xfs.yaml jobs/blogbench.yaml => ./blogbench-1HDD-btrfs.yaml # requires debian/ubuntu for now $ bin/setup-local --hdd /dev/sdaX ./blogbench-1HDD-btrfs.yaml $ bin/run-local ./blogbench-1HDD-btrfs.yaml The report is generated by the "sbin/compare" script. Thanks, Fengguang > On Sat, Aug 16, 2014 at 1:22 PM, Fengguang Wu <fengguang.wu@intel.com> wrote: > > Hi Chris, > > > > FYI, we noticed increased performance and reduced power consumption on > > > > commit 4c468fd74859d901c0b78b42bef189295e00d74f ("btrfs: disable strict file flushes for renames and truncates") > > > > test case: lkp-sb02/blogbench/1HDD-btrfs > > > > 0954d74f8f37a47 4c468fd74859d901c0b78b42b > > --------------- ------------------------- > > 1094 ± 1% +7.8% 1180 ± 2% TOTAL blogbench.write_score > > 1396 ±19% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.active_objs > > 1497 ±17% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.num_objs > > 426 ±45% -100.0% 0 ± 0% TOTAL proc-vmstat.nr_vmscan_write > > 1.02 ±38% +193.1% 2.99 ±37% TOTAL turbostat.%pc6 > > 0.12 ±48% +113.8% 0.25 ±29% TOTAL turbostat.%pc3 > > 0.38 ±18% +117.7% 0.84 ±34% TOTAL turbostat.%pc2 > > 19377 ±14% -50.9% 9520 ±20% TOTAL proc-vmstat.workingset_refault > > 44 ±41% +68.8% 75 ±28% TOTAL cpuidle.POLL.usage > > 31549 ± 1% +95.7% 61732 ± 1% TOTAL softirqs.BLOCK > > 4547 ±10% -38.3% 2804 ± 9% TOTAL slabinfo.btrfs_ordered_extent.active_objs > > 4628 ±10% -37.1% 2913 ± 9% TOTAL slabinfo.btrfs_ordered_extent.num_objs > > 17597 ± 8% -30.2% 12291 ±14% TOTAL proc-vmstat.nr_writeback > > 70335 ± 8% -30.1% 49174 ±14% TOTAL meminfo.Writeback > > 3606 ± 6% -29.1% 2556 ±10% TOTAL slabinfo.mnt_cache.active_objs > > 14763 ±12% -29.9% 10350 ± 8% TOTAL proc-vmstat.nr_dirty > > 3766 ± 5% -27.8% 2720 ±10% TOTAL slabinfo.mnt_cache.num_objs > > 3509 ± 6% -28.5% 2510 ±11% TOTAL slabinfo.kmalloc-4096.active_objs > > 59201 ±11% -30.1% 41396 ± 8% TOTAL meminfo.Dirty > > 479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.num_slabs > > 479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.active_slabs > > 3636 ± 6% -26.6% 2669 ±10% TOTAL slabinfo.kmalloc-4096.num_objs > > 6040 ± 8% -28.6% 4314 ± 6% TOTAL slabinfo.kmalloc-96.num_objs > > 5358 ± 5% -25.1% 4011 ± 7% TOTAL slabinfo.kmalloc-96.active_objs > > 757208 ± 4% -22.1% 589874 ± 4% TOTAL meminfo.MemFree > > 189508 ± 4% -22.2% 147518 ± 4% TOTAL proc-vmstat.nr_free_pages > > 762781 ± 4% -21.1% 601525 ± 4% TOTAL vmstat.memory.free > > 10491 ± 2% -16.8% 8725 ± 2% TOTAL slabinfo.kmalloc-64.num_objs > > 2513 ± 4% +16.3% 2923 ± 4% TOTAL slabinfo.kmalloc-128.active_objs > > 9768 ± 3% -15.1% 8298 ± 1% TOTAL slabinfo.kmalloc-64.active_objs > > 2627 ± 4% +14.0% 2995 ± 4% TOTAL slabinfo.kmalloc-128.num_objs > > 96242 ± 2% +15.5% 111120 ± 2% TOTAL slabinfo.btrfs_path.active_objs > > 3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.num_slabs > > 3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.active_slabs > > 96580 ± 2% +15.1% 111132 ± 2% TOTAL slabinfo.btrfs_path.num_objs > > 2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.num_slabs > > 2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.active_slabs > > 106133 ± 2% +13.5% 120434 ± 1% TOTAL slabinfo.btrfs_extent_state.num_objs > > 104326 ± 2% +12.3% 117189 ± 1% TOTAL slabinfo.btrfs_extent_state.active_objs > > 110759 ± 2% +13.4% 125640 ± 2% TOTAL slabinfo.btrfs_inode.active_objs > > 110759 ± 2% +13.4% 125642 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_objs > > 4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_slabs > > 4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_slabs > > 110797 ± 2% +13.4% 125663 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_objs > > 110815 ± 2% +13.4% 125669 ± 2% TOTAL slabinfo.btrfs_inode.num_objs > > 6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.num_slabs > > 6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.active_slabs > > 5607 ± 3% -11.0% 4991 ± 3% TOTAL slabinfo.kmalloc-256.active_objs > > 6077 ± 2% -9.9% 5476 ± 3% TOTAL slabinfo.kmalloc-256.num_objs > > 11153 ± 1% -7.7% 10295 ± 2% TOTAL proc-vmstat.nr_slab_unreclaimable > > 547824 ± 3% +16.5% 638368 ± 8% TOTAL meminfo.Inactive(file) > > 112124 ± 2% +11.6% 125105 ± 2% TOTAL slabinfo.radix_tree_node.active_objs > > 112169 ± 2% +11.6% 125134 ± 2% TOTAL slabinfo.radix_tree_node.num_objs > > 4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.num_slabs > > 4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.active_slabs > > 551119 ± 3% +16.4% 641663 ± 8% TOTAL meminfo.Inactive > > 285596 ± 2% +11.4% 318160 ± 2% TOTAL meminfo.SReclaimable > > 156 ± 3% +118.0% 340 ± 2% TOTAL iostat.sda.w/s > > 282 ± 3% -43.2% 160 ± 3% TOTAL iostat.sda.avgrq-sz > > 1.45 ±12% -28.9% 1.03 ±18% TOTAL iostat.sda.rrqm/s > > 633 ± 2% -26.5% 465 ± 2% TOTAL iostat.sda.wrqm/s > > 154423 ± 5% +17.4% 181309 ± 3% TOTAL time.voluntary_context_switches > > 536 ± 5% -11.5% 474 ± 9% TOTAL iostat.sda.await > > 102.71 ± 5% +10.4% 113.36 ± 6% TOTAL iostat.sda.avgqu-sz > > 20842 ± 2% -6.5% 19493 ± 2% TOTAL iostat.sda.wkB/s > > 20856 ± 2% -6.4% 19525 ± 2% TOTAL vmstat.io.bo > > 75.48 ± 4% -6.9% 70.27 ± 5% TOTAL turbostat.%c0 > > 285 ± 4% -6.6% 266 ± 5% TOTAL time.percent_of_cpu_this_job_got > > 34.58 ± 2% -5.5% 32.68 ± 3% TOTAL turbostat.Cor_W > > 39.86 ± 2% -5.1% 37.82 ± 3% TOTAL turbostat.Pkg_W > > 5805 ± 1% -4.3% 5558 ± 3% TOTAL vmstat.system.in > > 10069454 ± 1% +6.3% 10699830 ± 1% TOTAL time.file_system_outputs > > > > > > Disclaimer: > > Results have been estimated based on internal Intel analysis and are provided > > for informational purposes only. Any difference in system hardware or software > > design or configuration may affect actual performance. > > > > Thanks, > > Fengguang > > > > -- > Abhay ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [btrfs] 4c468fd7485: +7.8% blogbench.write_score, -5.1% turbostat.Pkg_W @ 2014-08-16 13:10 ` Fengguang Wu 0 siblings, 0 replies; 16+ messages in thread From: Fengguang Wu @ 2014-08-16 13:10 UTC (permalink / raw) To: lkp [-- Attachment #1: Type: text/plain, Size: 7934 bytes --] Hi Abhay, On Sat, Aug 16, 2014 at 05:30:35PM +0530, Abhay Sachan wrote: > Hi Fengguag, > Sorry for the out of topic question, but what benchmark is this? > I have heard about blogbench, but it doesn't give output in this format AFAIK. It is blogbench run in the lkp-tests framework. https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/ It will collect various system stats when blogbench runs. Then it presents you the collected blogbench stats together with slabinfo, meminfo, proc-vmstat, turbostat, softirqs etc. stats. The basic steps to reproduce this report are $ split-job jobs/blogbench.yaml jobs/blogbench.yaml => ./blogbench-1HDD-ext4.yaml jobs/blogbench.yaml => ./blogbench-1HDD-xfs.yaml jobs/blogbench.yaml => ./blogbench-1HDD-btrfs.yaml # requires debian/ubuntu for now $ bin/setup-local --hdd /dev/sdaX ./blogbench-1HDD-btrfs.yaml $ bin/run-local ./blogbench-1HDD-btrfs.yaml The report is generated by the "sbin/compare" script. Thanks, Fengguang > On Sat, Aug 16, 2014 at 1:22 PM, Fengguang Wu <fengguang.wu@intel.com> wrote: > > Hi Chris, > > > > FYI, we noticed increased performance and reduced power consumption on > > > > commit 4c468fd74859d901c0b78b42bef189295e00d74f ("btrfs: disable strict file flushes for renames and truncates") > > > > test case: lkp-sb02/blogbench/1HDD-btrfs > > > > 0954d74f8f37a47 4c468fd74859d901c0b78b42b > > --------------- ------------------------- > > 1094 ± 1% +7.8% 1180 ± 2% TOTAL blogbench.write_score > > 1396 ±19% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.active_objs > > 1497 ±17% -100.0% 0 ± 0% TOTAL slabinfo.btrfs_delalloc_work.num_objs > > 426 ±45% -100.0% 0 ± 0% TOTAL proc-vmstat.nr_vmscan_write > > 1.02 ±38% +193.1% 2.99 ±37% TOTAL turbostat.%pc6 > > 0.12 ±48% +113.8% 0.25 ±29% TOTAL turbostat.%pc3 > > 0.38 ±18% +117.7% 0.84 ±34% TOTAL turbostat.%pc2 > > 19377 ±14% -50.9% 9520 ±20% TOTAL proc-vmstat.workingset_refault > > 44 ±41% +68.8% 75 ±28% TOTAL cpuidle.POLL.usage > > 31549 ± 1% +95.7% 61732 ± 1% TOTAL softirqs.BLOCK > > 4547 ±10% -38.3% 2804 ± 9% TOTAL slabinfo.btrfs_ordered_extent.active_objs > > 4628 ±10% -37.1% 2913 ± 9% TOTAL slabinfo.btrfs_ordered_extent.num_objs > > 17597 ± 8% -30.2% 12291 ±14% TOTAL proc-vmstat.nr_writeback > > 70335 ± 8% -30.1% 49174 ±14% TOTAL meminfo.Writeback > > 3606 ± 6% -29.1% 2556 ±10% TOTAL slabinfo.mnt_cache.active_objs > > 14763 ±12% -29.9% 10350 ± 8% TOTAL proc-vmstat.nr_dirty > > 3766 ± 5% -27.8% 2720 ±10% TOTAL slabinfo.mnt_cache.num_objs > > 3509 ± 6% -28.5% 2510 ±11% TOTAL slabinfo.kmalloc-4096.active_objs > > 59201 ±11% -30.1% 41396 ± 8% TOTAL meminfo.Dirty > > 479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.num_slabs > > 479 ±13% -30.5% 333 ±10% TOTAL slabinfo.kmalloc-4096.active_slabs > > 3636 ± 6% -26.6% 2669 ±10% TOTAL slabinfo.kmalloc-4096.num_objs > > 6040 ± 8% -28.6% 4314 ± 6% TOTAL slabinfo.kmalloc-96.num_objs > > 5358 ± 5% -25.1% 4011 ± 7% TOTAL slabinfo.kmalloc-96.active_objs > > 757208 ± 4% -22.1% 589874 ± 4% TOTAL meminfo.MemFree > > 189508 ± 4% -22.2% 147518 ± 4% TOTAL proc-vmstat.nr_free_pages > > 762781 ± 4% -21.1% 601525 ± 4% TOTAL vmstat.memory.free > > 10491 ± 2% -16.8% 8725 ± 2% TOTAL slabinfo.kmalloc-64.num_objs > > 2513 ± 4% +16.3% 2923 ± 4% TOTAL slabinfo.kmalloc-128.active_objs > > 9768 ± 3% -15.1% 8298 ± 1% TOTAL slabinfo.kmalloc-64.active_objs > > 2627 ± 4% +14.0% 2995 ± 4% TOTAL slabinfo.kmalloc-128.num_objs > > 96242 ± 2% +15.5% 111120 ± 2% TOTAL slabinfo.btrfs_path.active_objs > > 3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.num_slabs > > 3448 ± 2% +15.1% 3968 ± 2% TOTAL slabinfo.btrfs_path.active_slabs > > 96580 ± 2% +15.1% 111132 ± 2% TOTAL slabinfo.btrfs_path.num_objs > > 2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.num_slabs > > 2526 ± 2% +13.5% 2867 ± 1% TOTAL slabinfo.btrfs_extent_state.active_slabs > > 106133 ± 2% +13.5% 120434 ± 1% TOTAL slabinfo.btrfs_extent_state.num_objs > > 104326 ± 2% +12.3% 117189 ± 1% TOTAL slabinfo.btrfs_extent_state.active_objs > > 110759 ± 2% +13.4% 125640 ± 2% TOTAL slabinfo.btrfs_inode.active_objs > > 110759 ± 2% +13.4% 125642 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_objs > > 4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_slabs > > 4261 ± 2% +13.4% 4832 ± 2% TOTAL slabinfo.btrfs_delayed_node.active_slabs > > 110797 ± 2% +13.4% 125663 ± 2% TOTAL slabinfo.btrfs_delayed_node.num_objs > > 110815 ± 2% +13.4% 125669 ± 2% TOTAL slabinfo.btrfs_inode.num_objs > > 6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.num_slabs > > 6926 ± 2% +13.4% 7853 ± 2% TOTAL slabinfo.btrfs_inode.active_slabs > > 5607 ± 3% -11.0% 4991 ± 3% TOTAL slabinfo.kmalloc-256.active_objs > > 6077 ± 2% -9.9% 5476 ± 3% TOTAL slabinfo.kmalloc-256.num_objs > > 11153 ± 1% -7.7% 10295 ± 2% TOTAL proc-vmstat.nr_slab_unreclaimable > > 547824 ± 3% +16.5% 638368 ± 8% TOTAL meminfo.Inactive(file) > > 112124 ± 2% +11.6% 125105 ± 2% TOTAL slabinfo.radix_tree_node.active_objs > > 112169 ± 2% +11.6% 125134 ± 2% TOTAL slabinfo.radix_tree_node.num_objs > > 4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.num_slabs > > 4005 ± 2% +11.6% 4468 ± 2% TOTAL slabinfo.radix_tree_node.active_slabs > > 551119 ± 3% +16.4% 641663 ± 8% TOTAL meminfo.Inactive > > 285596 ± 2% +11.4% 318160 ± 2% TOTAL meminfo.SReclaimable > > 156 ± 3% +118.0% 340 ± 2% TOTAL iostat.sda.w/s > > 282 ± 3% -43.2% 160 ± 3% TOTAL iostat.sda.avgrq-sz > > 1.45 ±12% -28.9% 1.03 ±18% TOTAL iostat.sda.rrqm/s > > 633 ± 2% -26.5% 465 ± 2% TOTAL iostat.sda.wrqm/s > > 154423 ± 5% +17.4% 181309 ± 3% TOTAL time.voluntary_context_switches > > 536 ± 5% -11.5% 474 ± 9% TOTAL iostat.sda.await > > 102.71 ± 5% +10.4% 113.36 ± 6% TOTAL iostat.sda.avgqu-sz > > 20842 ± 2% -6.5% 19493 ± 2% TOTAL iostat.sda.wkB/s > > 20856 ± 2% -6.4% 19525 ± 2% TOTAL vmstat.io.bo > > 75.48 ± 4% -6.9% 70.27 ± 5% TOTAL turbostat.%c0 > > 285 ± 4% -6.6% 266 ± 5% TOTAL time.percent_of_cpu_this_job_got > > 34.58 ± 2% -5.5% 32.68 ± 3% TOTAL turbostat.Cor_W > > 39.86 ± 2% -5.1% 37.82 ± 3% TOTAL turbostat.Pkg_W > > 5805 ± 1% -4.3% 5558 ± 3% TOTAL vmstat.system.in > > 10069454 ± 1% +6.3% 10699830 ± 1% TOTAL time.file_system_outputs > > > > > > Disclaimer: > > Results have been estimated based on internal Intel analysis and are provided > > for informational purposes only. Any difference in system hardware or software > > design or configuration may affect actual performance. > > > > Thanks, > > Fengguang > > > > -- > Abhay ^ permalink raw reply [flat|nested] 16+ messages in thread
* [btrfs] 8d875f95: xfstests.generic.226.fail 2014-08-16 7:52 ` Fengguang Wu @ 2014-08-19 11:58 ` Fengguang Wu -1 siblings, 0 replies; 16+ messages in thread From: Fengguang Wu @ 2014-08-19 11:58 UTC (permalink / raw) To: Chris Mason; +Cc: Dave Hansen, LKML, lkp, linux-btrfs, Abhay Sachan Hi Chris, We noticed an xfstests failure on commit 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes for renames and truncates") It's 100% reproducible in the 5 test runs. test case: snb-drag/xfstests/4HDD-btrfs-generic-mid 27b9a8122ff71a8 8d875f95da43c6a8f18f77869 --------------- ------------------------- %change %stddev | / 0 +Inf% 1 ± 0% TOTAL xfstests.generic.226.fail Thanks, Fengguang ^ permalink raw reply [flat|nested] 16+ messages in thread
* [btrfs] 8d875f95: xfstests.generic.226.fail @ 2014-08-19 11:58 ` Fengguang Wu 0 siblings, 0 replies; 16+ messages in thread From: Fengguang Wu @ 2014-08-19 11:58 UTC (permalink / raw) To: lkp [-- Attachment #1: Type: text/plain, Size: 550 bytes --] Hi Chris, We noticed an xfstests failure on commit 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes for renames and truncates") It's 100% reproducible in the 5 test runs. test case: snb-drag/xfstests/4HDD-btrfs-generic-mid 27b9a8122ff71a8 8d875f95da43c6a8f18f77869 --------------- ------------------------- %change %stddev | / 0 +Inf% 1 ± 0% TOTAL xfstests.generic.226.fail Thanks, Fengguang ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [btrfs] 8d875f95: xfstests.generic.226.fail 2014-08-19 11:58 ` Fengguang Wu @ 2014-08-19 14:23 ` David Sterba -1 siblings, 0 replies; 16+ messages in thread From: David Sterba @ 2014-08-19 14:23 UTC (permalink / raw) To: Fengguang Wu Cc: Chris Mason, Dave Hansen, LKML, lkp, linux-btrfs, Abhay Sachan On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote: > We noticed an xfstests failure on commit > > 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes for renames and truncates") > > It's 100% reproducible in the 5 test runs. Same here, different mkfs configurations. generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see /root/xfstests/results//generic/226.out.bad) --- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200 +++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200 @@ -1,6 +1,8 @@ QA output created by 226 --> mkfs 256m filesystem --> 16 buffered 64m writes in a loop -1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +1 2 3 4 pwrite64: No space left on device +5 6 7 8 9 10 11 12 pwrite64: No space left on device +13 14 15 16 enospc on a small filesystem (256M) # btrfs fi df /mnt/a2 System, single: total=4.00MiB, used=4.00KiB Data+Metadata, single: total=252.00MiB, used=31.09MiB GlobalReserve, single: total=4.00MiB, used=0.00B $ df -h /mnt/a2 Filesystem Size Used Avail Use% Mounted on /dev/sda9 256M 16M 241M 6% /mnt/a2 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [btrfs] 8d875f95: xfstests.generic.226.fail @ 2014-08-19 14:23 ` David Sterba 0 siblings, 0 replies; 16+ messages in thread From: David Sterba @ 2014-08-19 14:23 UTC (permalink / raw) To: lkp [-- Attachment #1: Type: text/plain, Size: 1231 bytes --] On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote: > We noticed an xfstests failure on commit > > 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes for renames and truncates") > > It's 100% reproducible in the 5 test runs. Same here, different mkfs configurations. generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see /root/xfstests/results//generic/226.out.bad) --- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200 +++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200 @@ -1,6 +1,8 @@ QA output created by 226 --> mkfs 256m filesystem --> 16 buffered 64m writes in a loop -1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 +1 2 3 4 pwrite64: No space left on device +5 6 7 8 9 10 11 12 pwrite64: No space left on device +13 14 15 16 enospc on a small filesystem (256M) # btrfs fi df /mnt/a2 System, single: total=4.00MiB, used=4.00KiB Data+Metadata, single: total=252.00MiB, used=31.09MiB GlobalReserve, single: total=4.00MiB, used=0.00B $ df -h /mnt/a2 Filesystem Size Used Avail Use% Mounted on /dev/sda9 256M 16M 241M 6% /mnt/a2 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [btrfs] 8d875f95: xfstests.generic.226.fail 2014-08-19 14:23 ` David Sterba @ 2014-08-19 14:58 ` Chris Mason -1 siblings, 0 replies; 16+ messages in thread From: Chris Mason @ 2014-08-19 14:58 UTC (permalink / raw) To: dsterba, Fengguang Wu, Dave Hansen, LKML, lkp, linux-btrfs, Abhay Sachan On 08/19/2014 10:23 AM, David Sterba wrote: > On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote: >> We noticed an xfstests failure on commit >> >> 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes for renames and truncates") >> >> It's 100% reproducible in the 5 test runs. > > Same here, different mkfs configurations. > > generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see /root/xfstests/results//generic/226.out.bad) > --- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200 > +++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200 > @@ -1,6 +1,8 @@ > QA output created by 226 > --> mkfs 256m filesystem > --> 16 buffered 64m writes in a loop > -1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 > +1 2 3 4 pwrite64: No space left on device > +5 6 7 8 9 10 11 12 pwrite64: No space left on device > +13 14 15 16 > > enospc on a small filesystem (256M) I'm calling filemap flush more often, but otherwise everything else is the same. I'll take a look. -chris ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [btrfs] 8d875f95: xfstests.generic.226.fail @ 2014-08-19 14:58 ` Chris Mason 0 siblings, 0 replies; 16+ messages in thread From: Chris Mason @ 2014-08-19 14:58 UTC (permalink / raw) To: lkp [-- Attachment #1: Type: text/plain, Size: 1124 bytes --] On 08/19/2014 10:23 AM, David Sterba wrote: > On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote: >> We noticed an xfstests failure on commit >> >> 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes for renames and truncates") >> >> It's 100% reproducible in the 5 test runs. > > Same here, different mkfs configurations. > > generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see /root/xfstests/results//generic/226.out.bad) > --- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200 > +++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200 > @@ -1,6 +1,8 @@ > QA output created by 226 > --> mkfs 256m filesystem > --> 16 buffered 64m writes in a loop > -1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 > +1 2 3 4 pwrite64: No space left on device > +5 6 7 8 9 10 11 12 pwrite64: No space left on device > +13 14 15 16 > > enospc on a small filesystem (256M) I'm calling filemap flush more often, but otherwise everything else is the same. I'll take a look. -chris ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [btrfs] 8d875f95: xfstests.generic.226.fail 2014-08-19 14:58 ` Chris Mason @ 2014-08-20 10:52 ` Miao Xie -1 siblings, 0 replies; 16+ messages in thread From: Miao Xie @ 2014-08-20 10:52 UTC (permalink / raw) To: Chris Mason, dsterba, Fengguang Wu, Dave Hansen, LKML, lkp, linux-btrfs, Abhay Sachan On Tue, 19 Aug 2014 10:58:09 -0400, Chris Mason wrote: > On 08/19/2014 10:23 AM, David Sterba wrote: >> On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote: >>> We noticed an xfstests failure on commit >>> >>> 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes for renames and truncates") >>> >>> It's 100% reproducible in the 5 test runs. >> >> Same here, different mkfs configurations. >> >> generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see /root/xfstests/results//generic/226.out.bad) >> --- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200 >> +++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200 >> @@ -1,6 +1,8 @@ >> QA output created by 226 >> --> mkfs 256m filesystem >> --> 16 buffered 64m writes in a loop >> -1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 >> +1 2 3 4 pwrite64: No space left on device >> +5 6 7 8 9 10 11 12 pwrite64: No space left on device >> +13 14 15 16 >> >> enospc on a small filesystem (256M) > > I'm calling filemap flush more often, but otherwise everything else is > the same. I'll take a look. The above patch also introduced a performance regression(~70%DOWN). We can reproduce this regression by fio, here is the config: [global] ioengine=falloc iodepth=1 direct=0 buffered=0 directory=<mnt> nrfiles=1 filesize=100m group_reporting [sequential aio-dio write] stonewall ioengine=posixaio numjobs=1 iodepth=128 buffered=0 direct=0 rw=write bs=64k filename=fragmented_file I found the problem is caused by the following function: int btrfs_release_file(struct inode *inode, struct file *filp) { ... filemap_flush(inode->i_mapping); return 0; } I don't think we need flush file at most situation. Ext4 flushes the file only after someone truncate the file to be zero-length, I don't know the real reason why ext4 flush the file only after the file is truncated, someone said it is to reduce the risk that the users find a zero-length file after a crash, which happens after truncate-write-close process. If we change btrfs_release_file by ext4's implementation, both the failure of xfstests's generic/226 and performance regression can be fixed. Thanks Miao > > -chris > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [btrfs] 8d875f95: xfstests.generic.226.fail @ 2014-08-20 10:52 ` Miao Xie 0 siblings, 0 replies; 16+ messages in thread From: Miao Xie @ 2014-08-20 10:52 UTC (permalink / raw) To: lkp [-- Attachment #1: Type: text/plain, Size: 2600 bytes --] On Tue, 19 Aug 2014 10:58:09 -0400, Chris Mason wrote: > On 08/19/2014 10:23 AM, David Sterba wrote: >> On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote: >>> We noticed an xfstests failure on commit >>> >>> 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes for renames and truncates") >>> >>> It's 100% reproducible in the 5 test runs. >> >> Same here, different mkfs configurations. >> >> generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see /root/xfstests/results//generic/226.out.bad) >> --- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200 >> +++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200 >> @@ -1,6 +1,8 @@ >> QA output created by 226 >> --> mkfs 256m filesystem >> --> 16 buffered 64m writes in a loop >> -1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 >> +1 2 3 4 pwrite64: No space left on device >> +5 6 7 8 9 10 11 12 pwrite64: No space left on device >> +13 14 15 16 >> >> enospc on a small filesystem (256M) > > I'm calling filemap flush more often, but otherwise everything else is > the same. I'll take a look. The above patch also introduced a performance regression(~70%DOWN). We can reproduce this regression by fio, here is the config: [global] ioengine=falloc iodepth=1 direct=0 buffered=0 directory=<mnt> nrfiles=1 filesize=100m group_reporting [sequential aio-dio write] stonewall ioengine=posixaio numjobs=1 iodepth=128 buffered=0 direct=0 rw=write bs=64k filename=fragmented_file I found the problem is caused by the following function: int btrfs_release_file(struct inode *inode, struct file *filp) { ... filemap_flush(inode->i_mapping); return 0; } I don't think we need flush file at most situation. Ext4 flushes the file only after someone truncate the file to be zero-length, I don't know the real reason why ext4 flush the file only after the file is truncated, someone said it is to reduce the risk that the users find a zero-length file after a crash, which happens after truncate-write-close process. If we change btrfs_release_file by ext4's implementation, both the failure of xfstests's generic/226 and performance regression can be fixed. Thanks Miao > > -chris > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [btrfs] 8d875f95: xfstests.generic.226.fail 2014-08-20 10:52 ` Miao Xie @ 2014-08-20 14:07 ` Chris Mason -1 siblings, 0 replies; 16+ messages in thread From: Chris Mason @ 2014-08-20 14:07 UTC (permalink / raw) To: miaox, dsterba, Fengguang Wu, Dave Hansen, LKML, lkp, linux-btrfs, Abhay Sachan On 08/20/2014 06:52 AM, Miao Xie wrote: > On Tue, 19 Aug 2014 10:58:09 -0400, Chris Mason wrote: >> On 08/19/2014 10:23 AM, David Sterba wrote: >>> On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote: >>>> We noticed an xfstests failure on commit >>>> >>>> 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes for renames and truncates") >>>> >>>> It's 100% reproducible in the 5 test runs. >>> >>> Same here, different mkfs configurations. >>> >>> generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see /root/xfstests/results//generic/226.out.bad) >>> --- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200 >>> +++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200 >>> @@ -1,6 +1,8 @@ >>> QA output created by 226 >>> --> mkfs 256m filesystem >>> --> 16 buffered 64m writes in a loop >>> -1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 >>> +1 2 3 4 pwrite64: No space left on device >>> +5 6 7 8 9 10 11 12 pwrite64: No space left on device >>> +13 14 15 16 >>> >>> enospc on a small filesystem (256M) >> >> I'm calling filemap flush more often, but otherwise everything else is >> the same. I'll take a look. > > I found the problem is caused by the following function: > > int btrfs_release_file(struct inode *inode, struct file *filp) > { > ... > filemap_flush(inode->i_mapping); > return 0; > } > > I don't think we need flush file at most situation. Ext4 flushes the file only > after someone truncate the file to be zero-length, I don't know the real reason > why ext4 flush the file only after the file is truncated, someone said it is to > reduce the risk that the users find a zero-length file after a crash, which happens > after truncate-write-close process. > > If we change btrfs_release_file by ext4's implementation, both the failure of > xfstests's generic/226 and performance regression can be fixed. > You're completely right, my original had more checks here and I stripped them out by accident. Fixing, thanks! -chris ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [btrfs] 8d875f95: xfstests.generic.226.fail @ 2014-08-20 14:07 ` Chris Mason 0 siblings, 0 replies; 16+ messages in thread From: Chris Mason @ 2014-08-20 14:07 UTC (permalink / raw) To: lkp [-- Attachment #1: Type: text/plain, Size: 2135 bytes --] On 08/20/2014 06:52 AM, Miao Xie wrote: > On Tue, 19 Aug 2014 10:58:09 -0400, Chris Mason wrote: >> On 08/19/2014 10:23 AM, David Sterba wrote: >>> On Tue, Aug 19, 2014 at 07:58:20PM +0800, Fengguang Wu wrote: >>>> We noticed an xfstests failure on commit >>>> >>>> 8d875f95da43c6a8f18f77869f2ef26e9594fecc ("btrfs: disable strict file flushes for renames and truncates") >>>> >>>> It's 100% reproducible in the 5 test runs. >>> >>> Same here, different mkfs configurations. >>> >>> generic/226 28s ... [16:11:52] [16:12:55] - output mismatch (see /root/xfstests/results//generic/226.out.bad) >>> --- tests/generic/226.out 2013-05-29 17:16:03.000000000 +0200 >>> +++ /root/xfstests/results//generic/226.out.bad 2014-08-19 16:12:55.000000000 +0200 >>> @@ -1,6 +1,8 @@ >>> QA output created by 226 >>> --> mkfs 256m filesystem >>> --> 16 buffered 64m writes in a loop >>> -1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 >>> +1 2 3 4 pwrite64: No space left on device >>> +5 6 7 8 9 10 11 12 pwrite64: No space left on device >>> +13 14 15 16 >>> >>> enospc on a small filesystem (256M) >> >> I'm calling filemap flush more often, but otherwise everything else is >> the same. I'll take a look. > > I found the problem is caused by the following function: > > int btrfs_release_file(struct inode *inode, struct file *filp) > { > ... > filemap_flush(inode->i_mapping); > return 0; > } > > I don't think we need flush file at most situation. Ext4 flushes the file only > after someone truncate the file to be zero-length, I don't know the real reason > why ext4 flush the file only after the file is truncated, someone said it is to > reduce the risk that the users find a zero-length file after a crash, which happens > after truncate-write-close process. > > If we change btrfs_release_file by ext4's implementation, both the failure of > xfstests's generic/226 and performance regression can be fixed. > You're completely right, my original had more checks here and I stripped them out by accident. Fixing, thanks! -chris ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH] Btrfs: fix filemap_flush call in btrfs_file_release 2014-08-20 10:52 ` Miao Xie @ 2014-08-20 14:48 ` Chris Mason -1 siblings, 0 replies; 16+ messages in thread From: Chris Mason @ 2014-08-20 14:48 UTC (permalink / raw) To: miaox, dsterba, Fengguang Wu, Dave Hansen, LKML, lkp, linux-btrfs, Abhay Sachan We should only be flushing on close if the file was flagged as needing it during truncate. I broke this with my ordered data vs transaction commit deadlock fix. Thanks to Miao Xie for catching this. Signed-off-by: Chris Mason <clm@fb.com> Reported-by: Miao Xie <miaox@cn.fujitsu.com> Reported-by: Fengguang Wu <fengguang.wu@intel.com> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index f15c13f..36861b7 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1840,7 +1840,15 @@ int btrfs_release_file(struct inode *inode, struct file *filp) { if (filp->private_data) btrfs_ioctl_trans_end(filp); - filemap_flush(inode->i_mapping); + /* + * ordered_data_close is set by settattr when we are about to truncate + * a file from a non-zero size to a zero size. This tries to + * flush down new bytes that may have been written if the + * application were using truncate to replace a file in place. + */ + if (test_and_clear_bit(BTRFS_INODE_ORDERED_DATA_CLOSE, + &BTRFS_I(inode)->runtime_flags)) + filemap_flush(inode->i_mapping); return 0; } ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH] Btrfs: fix filemap_flush call in btrfs_file_release @ 2014-08-20 14:48 ` Chris Mason 0 siblings, 0 replies; 16+ messages in thread From: Chris Mason @ 2014-08-20 14:48 UTC (permalink / raw) To: lkp [-- Attachment #1: Type: text/plain, Size: 1103 bytes --] We should only be flushing on close if the file was flagged as needing it during truncate. I broke this with my ordered data vs transaction commit deadlock fix. Thanks to Miao Xie for catching this. Signed-off-by: Chris Mason <clm@fb.com> Reported-by: Miao Xie <miaox@cn.fujitsu.com> Reported-by: Fengguang Wu <fengguang.wu@intel.com> diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index f15c13f..36861b7 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -1840,7 +1840,15 @@ int btrfs_release_file(struct inode *inode, struct file *filp) { if (filp->private_data) btrfs_ioctl_trans_end(filp); - filemap_flush(inode->i_mapping); + /* + * ordered_data_close is set by settattr when we are about to truncate + * a file from a non-zero size to a zero size. This tries to + * flush down new bytes that may have been written if the + * application were using truncate to replace a file in place. + */ + if (test_and_clear_bit(BTRFS_INODE_ORDERED_DATA_CLOSE, + &BTRFS_I(inode)->runtime_flags)) + filemap_flush(inode->i_mapping); return 0; } ^ permalink raw reply related [flat|nested] 16+ messages in thread
end of thread, other threads:[~2014-08-20 14:49 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-08-16 7:52 [btrfs] 4c468fd7485: +7.8% blogbench.write_score, -5.1% turbostat.Pkg_W Fengguang Wu
2014-08-16 7:52 ` Fengguang Wu
[not found] ` <CAKHchJwQcH326Z8otiaXtKoKs6fH9s+e9BqJDi=H1bWKiuybAw@mail.gmail.com>
2014-08-16 13:10 ` Fengguang Wu
2014-08-16 13:10 ` Fengguang Wu
2014-08-19 11:58 ` [btrfs] 8d875f95: xfstests.generic.226.fail Fengguang Wu
2014-08-19 11:58 ` Fengguang Wu
2014-08-19 14:23 ` David Sterba
2014-08-19 14:23 ` David Sterba
2014-08-19 14:58 ` Chris Mason
2014-08-19 14:58 ` Chris Mason
2014-08-20 10:52 ` Miao Xie
2014-08-20 10:52 ` Miao Xie
2014-08-20 14:07 ` Chris Mason
2014-08-20 14:07 ` Chris Mason
2014-08-20 14:48 ` [PATCH] Btrfs: fix filemap_flush call in btrfs_file_release Chris Mason
2014-08-20 14:48 ` Chris Mason
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.