Re: Paging out when free memory is low but not exhausted (and available memory remains high)

[Chris Edwards <chris.edwards@otago.ac.nz>]

[-- Attachment #1: Type: text/plain, Size: 2048 bytes --]

Actually, I posted to soon - the behaviour is more subtle!

I noticed after my previous message that other system activity can apparently halt the page-outs temporarily. For example, after running Chrome for a while, the paging stopped (and the system conspicuously had quite a chunk of memory in the MAP category in xosview). After exiting Chrome and resetting swap and caches, the problem reappears.

I found that running glxgears concurrently also stops the page-outs. Some earlier testing with latencytop indicated long waits in the i915 driver, so I wonder if there is some interaction with the graphics system somehow. I've captured the /proc/vmstat data for such a test:

vmstat_5.5.0-rc6+patched_cedwards_2020-01-28.tar.gz

Timeline:

1580184360	run "stress --vm-bytes $(awk '/MemAvailable/{printf "%d\n", $2 * 0.9;}' < /proc/meminfo)k --vm-keep -m 1"
1580184370	run "dd if=/dev/sda of=/dev/null bs=1M"
1580184420	run "glxgears"
1580184430	glxgears display appears
1580184460	kill glxgears
1580184484	kill dd

Even more weirdly (perhaps further suggesting graphics interactions), moving the mouse pointer between (urxvt) terminal windows also stops the page-outs. I'm using the Notion tiling window manager, which uses focus-follows-mouse. Here is another vmstat capture, this time using the unpatched 5.5.0-rc6 kernel:

vmstat_5.5.0-rc6-unpatched_cedwards_2020-01-28.tar.gz

Timeline:

1580185680	run stress
1580185690	run dd
1580185720	move mouse pointer continuously between urxvt windows
1580185740	move mouse pointer only within one urxvt window
1580185750	stop mouse motion

Just as I'm writing this, I notice that the paging stops while Chrome has focus, but resumes when it loses focus! Running glxgears stops the paging even if the glxgears window does not have focus. This is on the generic unpatched 5.5.0-rc6 kernel, with `stress` and `dd` still running. Very odd - but perhaps it points toward a root cause somehow. I think it would be good to test on other hardware. :)

Best regards,
--
Chris

[-- Attachment #2: vmstat_5.5.0-rc6+patched_cedwards_2020-01-28.tar.gz --]
[-- Type: application/gzip, Size: 27061 bytes --]

[-- Attachment #3: vmstat_5.5.0-rc6-unpatched_cedwards_2020-01-28.tar.gz --]
[-- Type: application/gzip, Size: 15821 bytes --]