On Thu 23-08-18 14:10:28, Vlastimil Babka wrote: > 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 But please note that this is not from the time when the page cache dropped to the observed values. So we do not know what happened at the time. Anyway 277 THP pages paging out such a large page cache amount would be more than unexpected even for explicitly costly THP fault in methods. -- Michal Hocko SUSE Labs
