On Thu 30-01-25 12:19:38, Waiman Long wrote: > On 1/30/25 12:05 PM, Roman Gushchin wrote: > > On Thu, Jan 30, 2025 at 10:05:34AM -0500, Waiman Long wrote: [...] > > > > Why cannot they achieve the same with the existing events/metrics we > > > > already do provide? Most notably PSI which is properly accounted when > > > > a task is throttled due to memory.high throttling. > > > That will require the use of a userspace management agent that looks for > > > these stalling conditions and make the kill, if necessary. There are > > > certainly users out there that want to get some benefit of using memory.high > > > like early memory reclaim without the trouble of handling these kind of > > > stalling conditions. Could you expand more on that? As long as the memory is reasonably reclaimable then the hard (max) limit is exactly what you need. If you want to implement oom policy in the userspace you have high limit to get notifications about the memory pressure. Why this is insufficient? > > So you basically want to force the workload into some sort of a proactive > > reclaim but without an artificial slow down? > > It makes some sense to me, but > > 1) Idk if it deserves a new API, because it can be relatively easy implemented > > in userspace by a daemon which monitors cgroups usage and reclaims the memory > > if necessarily. No kernel changes are needed. > > 2) If new API is introduced, I think it's better to introduce a new limit, > > e.g. memory.target, keeping memory.high semantics intact. > > Yes, you are right about that. Introducing a new "memory.target" without > disturbing the existing "memory.high" semantics will work for me too. I thought those usecases want to kill misbehaving containers rather than burning time trying to reclaim. I do not understand how will such a new limit help to achieve that. -- Michal Hocko SUSE Labs
