On 08/22/2018 10:02 PM, Marinko Catovic wrote: >> It might be also interesting to do in the problematic state, instead of >> dropping caches: >> >> - save snapshot of /proc/vmstat and /proc/pagetypeinfo >> - echo 1 > /proc/sys/vm/compact_memory >> - save new snapshot of /proc/vmstat and /proc/pagetypeinfo > > There was just a worstcase in progress, about 100MB/10GB were used, > super-low perfomance, but could not see any improvement there after echo 1, > I watches this for about 3 minutes, the cache usage did not change. > > pagetypeinfo before echo https://pastebin.com/MjSgiMRL > pagetypeinfo 3min after echo https://pastebin.com/uWM6xGDd > > vmstat before echo https://pastebin.com/TjYSKNdE > vmstat 3min after echo https://pastebin.com/MqTibEKi OK, that confirms compaction is useless here. Thanks. It also shows that all orders except order-9 are in fact plentiful. Michal's earlier summary of the trace shows that most allocations are up to order-3 and should be fine, the exception is THP: 277 9 GFP_TRANSHUGE|__GFP_THISNODE Hmm it's actually interesting to see GFP_TRANSHUGE there and not GFP_TRANSHUGE_LIGHT. What's your thp defrag setting? (cat /sys/kernel/mm/transparent_hugepage/enabled). Maybe it's set to "always", or there's a heavily faulting process that's using madvise(MADV_HUGEPAGE). If that's the case, setting it to "defer" or even "never" could be a workaround.
