Thanks for the response Krishna,
>> Caches shrinking doesn't necessarily release the pages of a particular zone.
I thought kswap will try and reclaim fs cache first, before trying to page and
potentially swap out pages...
We have 2 numa nodes with the following zones (see below). Every two hours our
available free space reported by /proc/meminfo drops down to ~180MB and then we
see fs cache flushed followed by anonymous pages reclaimed. The total is
~2-3GB. The fs cache accounted for ~2GB. My understanding is kswapd should
stop reclaiming once free pages is above the high water mark, however we see
excessive swapping out freeing pages beyond the high water mark and impacting
the performance of a memory latency sensitive application.
The /proc/zoneinfo below doesn't correspond to the time the issue occurred, just
a example of what our host looks like. Unfortunately we don't have zoneinfo
persisted. We do have the buddyinfo persisted not sure if that would help.
Node 0, zone Normal
pages free 163947
min 11275
low 14093
high 16912
scanned 0
spanned 3145728
present 3102720
Node 1, zone DMA
pages free 3935
min 13
low 16
high 19
scanned 0
spanned 4095
present 3840
Node 1, zone DMA32
pages free 19524
min 3017
low 3771
high 4525
scanned 0
spanned 1044480
present 830385
Node 1, zone Normal
pages free 294707
min 8221
low 10276
high 12331
scanned 0
spanned 2293760
present 2262400
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>