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
