https://bugzilla.kernel.org/show_bug.cgi?id=202349 Hector Martin (hector@xxxxxxxxxxxxxx) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hector@xxxxxxxxxxxxxx --- Comment #13 from Hector Martin (hector@xxxxxxxxxxxxxx) --- I'm the author of the mentioned tweet. What I was seeing was that on a system with loads of free RAM, XFS reclaiming inodes would randomly block on IO. This is completely unexpected. I do expect that a system under memory and IO pressure ("used" memory, not just "available" memory used for clean caches) will block on IO during allocations that trigger writeback. I do *not* expect that on a system with tons of clean data to evict, but that is what I saw with XFS. I had a process writing real-time data to disk (on a moderately busy system with gigabytes of free RAM), and even though disk bandwidth was plenty to keep up with the data, I was seeing buffer underruns due to big random latency spikes. After I introduced a process in the pipeline doing up to several gigabytes of RAM buffering to even out the spikes, I was *still* getting the buffer input stuttering for several seconds, breaking the real-time capture. That's where I realized that a kernel pipe buffer allocation was somehow blocking on XFS doing IO. I would echo 3 > /proc/sys/vm/drop_caches, and latencies would become normal. I would then watch RAM used for caches slowly creep up, and when it hit 95% or so, latency would randomly shoot through the roof again. This is obviously broken behavior. Allocating from RAM used for caches should **never** block on IO. The system should never slow down because extra RAM is being used for caches. That is just insane. The whole point of using RAM for caches is to utilize otherwise wasted RAM. If this is causing allocations to block on IO when freeing said RAM, randomly causing huge latency spikes for everything, then that is broken. I've since switched to ext4 on the same disks and haven't had a problem ever since. -- You are receiving this mail because: You are watching the assignee of the bug.
