Re: [LSF/MM/BPF TOPIC] Measuring limits and enhancing buffered IO

Luis Chamberlain
2024-05-10T23:57:19Z

On Sat, Feb 24, 2024 at 05:57:43PM -0500, Chris Mason wrote:
> Going back to Luis's original email, I'd echo Willy's suggestion for
> profiles. Unless we're saturating memory bandwidth, buffered should be
> able to get much closer to O_DIRECT, just at a much higher overall cost.

I finally had some time to look beyond just "what locks" could be the
main culprit, David Bueso helped me review this, thanks!

Based on all the discussions on this insanely long thread, I do believe
the issue was the single threaded write-behind cache flushing back Chinner
noted.

Lifting the /proc/sys/vm/dirty_ratio from 20 to 90 keeps the profile
perky and nice with most top penalties seen just in userspace as seen in
the first paste exhibit a) below but as soon as we start throttling we
hit the profile on past exhibit b) below.

a) without the throttling:

Samples: 1M of event 'cycles:P', Event count (approx.): 1061541571785
Children Self Command Shared Object Symbol
+ 17.05% 16.85% fio fio [.] get_io_u ◆
+ 3.04% 0.01% fio [kernel.vmlinux] [k] entry_SYSCALL_64 ▒
+ 3.03% 0.02% fio [kernel.vmlinux] [k] do_syscall_64 ▒
+ 1.39% 0.04% fio [kernel.vmlinux] [k] __do_sys_io_uring_enter ▒
+ 1.33% 0.00% fio libc.so.6 [.] __GI___libc_open ▒
+ 1.33% 0.00% fio [kernel.vmlinux] [k] __x64_sys_openat ▒
+ 1.33% 0.00% fio [kernel.vmlinux] [k] do_sys_openat2 ▒
+ 1.33% 0.00% fio [unknown] [k] 0x312d6e65742f2f6d ▒
+ 1.33% 0.00% fio [kernel.vmlinux] [k] do_filp_open ▒
+ 1.33% 0.00% fio [kernel.vmlinux] [k] path_openat ▒
+ 1.29% 0.00% fio [kernel.vmlinux] [k] down_write ▒
+ 1.29% 0.00% fio [kernel.vmlinux] [k] rwsem_down_write_slowpath ▒
+ 1.26% 1.25% fio [kernel.vmlinux] [k] osq_lock ▒
+ 1.14% 0.00% fio fio [.] 0x000055bbb94449fa ▒
+ 1.14% 1.14% fio fio [.] 0x000000000002a9f5 ▒
+ 0.98% 0.00% fio [unknown] [k] 0x000055bbd6310520 ▒
+ 0.93% 0.00% fio fio [.] 0x000055bbb94b197b ▒
+ 0.89% 0.00% perf libc.so.6 [.] __GI___libc_write ▒
+ 0.89% 0.00% perf [kernel.vmlinux] [k] entry_SYSCALL_64 ▒
+ 0.88% 0.00% perf [kernel.vmlinux] [k] do_syscall_64 ▒
+ 0.86% 0.00% perf [kernel.vmlinux] [k] ksys_write ▒
+ 0.85% 0.01% perf [kernel.vmlinux] [k] vfs_write ▒
+ 0.83% 0.00% perf [ext4] [k] ext4_buffered_write_iter ▒
+ 0.81% 0.01% perf [kernel.vmlinux] [k] generic_perform_write ▒
+ 0.77% 0.02% fio [kernel.vmlinux] [k] io_submit_sqes ▒
+ 0.76% 0.00% kworker/u513:26 [kernel.vmlinux] [k] ret_from_fork_asm ▒
+ 0.76% 0.00% kworker/u513:26 [kernel.vmlinux] [k] ret_from_fork ▒
+ 0.76% 0.00% kworker/u513:26 [kernel.vmlinux] [k] kthread ▒
+ 0.76% 0.00% kworker/u513:26 [kernel.vmlinux] [k] worker_thread ▒
+ 0.76% 0.00% kworker/u513:26 [kernel.vmlinux] [k] process_one_work ▒
+ 0.76% 0.00% kworker/u513:26 [kernel.vmlinux] [k] wb_workfn ▒
+ 0.76% 0.00% kworker/u513:26 [kernel.vmlinux] [k] wb_writeback ▒
+ 0.76% 0.00% kworker/u513:26 [kernel.vmlinux] [k] __writeback_inodes_wb ▒
+ 0.76% 0.00% kworker/u513:26 [kernel.vmlinux] [k] writeback_sb_inodes ▒
+ 0.76% 0.00% kworker/u513:26 [kernel.vmlinux] [k] __writeback_single_inode ▒
+ 0.76% 0.00% kworker/u513:26 [kernel.vmlinux] [k] do_writepages ▒
+ 0.76% 0.00% kworker/u513:26 [xfs] [k] xfs_vm_writepages ▒
+ 0.75% 0.00% kworker/u513:26 [kernel.vmlinux] [k] submit_bio_noacct_nocheck ▒
+ 0.75% 0.00% kworker/u513:26 [kernel.vmlinux] [k] iomap_submit_ioend

So we see *more* penalty because of perf's own buffered IO writes of the
perf data than any writeback from from XFS.

a) when we hit throttling:

Samples: 1M of event 'cycles:P', Event count (approx.): 816903693659
Children Self Command Shared Object Symbol
+ 14.24% 14.06% fio fio [.] get_io_u ◆
+ 4.88% 0.00% kworker/u513:3- [kernel.vmlinux] [k] ret_from_fork_asm ▒
+ 4.88% 0.00% kworker/u513:3- [kernel.vmlinux] [k] ret_from_fork ▒
+ 4.88% 0.00% kworker/u513:3- [kernel.vmlinux] [k] kthread ▒
+ 4.88% 0.00% kworker/u513:3- [kernel.vmlinux] [k] worker_thread ▒
+ 4.88% 0.00% kworker/u513:3- [kernel.vmlinux] [k] process_one_work ▒
+ 4.88% 0.00% kworker/u513:3- [kernel.vmlinux] [k] wb_workfn ▒
+ 4.88% 0.00% kworker/u513:3- [kernel.vmlinux] [k] wb_writeback ▒
+ 4.88% 0.00% kworker/u513:3- [kernel.vmlinux] [k] __writeback_inodes_wb ▒
+ 4.88% 0.00% kworker/u513:3- [kernel.vmlinux] [k] writeback_sb_inodes ▒
+ 4.87% 0.00% kworker/u513:3- [kernel.vmlinux] [k] __writeback_single_inode ▒
+ 4.87% 0.00% kworker/u513:3- [kernel.vmlinux] [k] do_writepages ▒
+ 4.87% 0.00% kworker/u513:3- [xfs] [k] xfs_vm_writepages ▒
+ 4.82% 0.00% kworker/u513:3- [kernel.vmlinux] [k] iomap_submit_ioend ▒
+ 4.82% 0.00% kworker/u513:3- [kernel.vmlinux] [k] submit_bio_noacct_nocheck ▒
+ 4.82% 0.00% kworker/u513:3- [kernel.vmlinux] [k] __submit_bio ▒
+ 4.82% 0.04% kworker/u513:3- [nd_pmem] [k] pmem_submit_bio ▒
+ 4.78% 0.05% kworker/u513:3- [nd_pmem] [k] pmem_do_write

Although my focus was on measuring the limits of the page cache, this
thread also had a *slew* of ideas on how to improve that status quo,
pathological or not. We have to accept some workloads are clearly
pathological, but that's the point in coming up with limits and testing
the page cache. But since there were a slew of unexpected ideas spread
out this entire thread about general improvements, even for general use
cases, I've collected all of them and put them as notes for for review
for this topic at LSFMM.

Thanks all for the feedback!

Luis