[Bug 202349] Extreme desktop freezes during sustained write operations with XFS

[bugzilla-daemon@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=202349

Hector Martin (hector@marcansoft.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hector@marcansoft.com

--- Comment #13 from Hector Martin (hector@marcansoft.com) ---
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.