mjhjmtu

I tested Linux 4.18.16-200.fc28.x86_64, with 7.7G total RAM (free -h).

I have default vm.dirty* settings. dirty_background_ratio is 10, and dirty_ratio is 20.

This means Linux should begin writeout of dirty cache when it reaches 10% of RAM: 0.77G. Writers should block if it reaches 20% of RAM: 1.54G. Between those values, I believe that write() calls are supposed to be throttled (delayed) on a curve, to keep the dirty cache near a "setpoint" which is half-way in between: 1.155G.

• https://github.com/torvalds/linux/blob/v4.18/Documentation/sysctl/vm.txt


• No-I/O dirty throttling - LWN.net


• (dirty_background_ratio + dirty_ratio)/2 dirty data in
  total ... is an amount of dirty data when we start to throttle
  processes

I ran dd if=/dev/zero bs=1M of=~/test, and watched the dirty field in atop.

I saw dirty fluctuate pretty close to 0.5G. Never mind the "setpoint", this is even less than the dirty background threshold (0.77G)! How can this be? It is absolutely not what I would expect, based on the above documents. What am I missing?

dirty_expire_centisecs is 30000, so I don't think that can be the cause. I even tried lowering dirty_expire_centisecs to 100, and dirty_writeback_centisecs to 10, to see if that was limiting dirty. This did not change the result.

I initially wrote these observations as part of my post here: Why were "USB-stick stall" problems reported in 2013? Why wasn't this problem solved by the existing "No-I/O dirty throttling" code?