On Mon 04-05-20 12:23:51, Shakeel Butt wrote: [...] > *Potentially* useful for debugging versus actually beneficial for > "sweep before tear down" use-case. I definitely do not want to prevent you from achieving what you want/need. Let's get back to your argument on why you cannot use memory.high for this purpose and what is the actual difference from memory.max on the "sweep before removal". You've said : Yes that would work but remote charging concerns me. Remote charging : can still happen after the memcg is offlined and at the moment, high : reclaim does not work for remote memcg and the usage can go till max : or global pressure. This is most probably a misconfiguration and we : might not receive the warnings in the log ever. Setting memory.max to : 0 will definitely give such warnings. So essentially the only reason you are not using memory.high which would effectively achieve the same level of reclaim for your usecase is that potential future remote charges could get unnoticed. I have proposed to warn when charging to an offline memcg because that looks like a sign of bug to me. Having the hard limit clamped to 0 (or some other small value) would complain loud by the oom report and no eligible tasks message but it will unlikely help to stop such a usage because, well, there is nothing reclaimable and we force the charge in that case. So you are effectively in the memory.high like situation. So instead of potentially removing a useful information can we focus on the remote charging side of the problem and deal with it in a sensible way? That would make memory.high usable for your usecase and I still believe that this is what you should be using in the first place. -- Michal Hocko SUSE Labs
