On Tue, Apr 19, 2022 at 07:54:52PM -0400, Nico Pache wrote: > > > On 4/19/22 14:46, Johannes Weiner wrote: > > Hi Nico, > > > > On Tue, Apr 19, 2022 at 02:11:53PM -0400, Nico Pache wrote: > >> I think its is important to note the issue we are seeing has greatly improved > >> since the initial posting. However we have noticed that the issue is still > >> present (and significantly worse) when cgroupV1 is set. > >> > >> We were initially testing with CgroupV1 and later found that the issue was not > >> as bad in CgroupV2 (but was still an noticeable issue). This is also resulting > >> in the splitting of THPs in the host kernel. > > > > When swappiness is 0, cgroup limit reclaim has a fixed SCAN_FILE > > branch, so it shouldn't ever look at anon. I'm assuming you're getting > > global reclaim mixed in. Indeed, I think we can try harder not to swap > > for global reclaim if the user asks for that. > > > > Can you try the below patch? > Sadly this did not fix the V1 case. > > I will have to go back through my notes and over the code again to find what > difference between the two may be causing this issue. Im just starting to focus > on this issue again so my memory needs some refreshing of where I was last at. > > The good news is that with the current state of upstream the issue of swap > storms tearing down THPs seems to be minimized to sane amount with V2. > > My swappiness=0 solution was a minimal approach to regaining the 'avoid swapping > ANON' behavior that was previously there, but as Shakeel pointed out, there may > be something larger at play. So with my patch and swappiness=0 you get excessive swapping on v1 but not on v2? And the patch to avoid DEACTIVATE_ANON fixes it? If you haven't done so, it could be useful to litter shrink_node() and get_scan_count() with trace_printk() to try to make sense of all the decisions that result in it swapping.
