Hi, thanks for the detailed report. On Wed 25-11-20 12:39:56, Bruno Prémont wrote: [...] > Did memory.low meaning change between 5.7 and 5.9? The latest semantic change in the low limit protection semantic was introduced in 5.7 (recursive protection) but it requires an explicit enablinig. > From behavior it > feels as if inodes are not accounted to cgroup at all and kernel pushes > cgroups down to their memory.low by killing file cache if there is not > enough free memory to hold all promises (and not only when a cgroup > tries to use up to its promised amount of memory). Your counters indeed show that the low protection has been breached, most likely because the reclaim couldn't make any progress. Considering that this is the case for all/most of your cgroups it suggests that the memory pressure was global rather than limit imposed. In fact even top level cgroups got reclaimed below the low limit. This suggests that this is not likely to be memcg specific. It is more likely that this is a general memory reclaim regression for your workload. There were larger changes in that area. Be it lru balancing based on cost model by Johannes or working set tracking for anonymous pages by Joonsoo. Maybe even more. Both of them can influence page cache reclaim but you are suggesting that slab accounted memory is not reclaimed properly. I am not sure sure there were considerable changes there. Would it be possible to collect /prov/vmstat as well? -- Michal Hocko SUSE Labs
