On Mon 20-04-20 12:47:40, Tejun Heo wrote: [...] > > Coming back to this path series, to me, it seems like the patch series > > is contrary to the vision you are presenting. Though the users are not > > setting memory.[high|max] but they are setting swap.max and this > > series is asking to set one more tunable i.e. swap.high. The approach > > more consistent with the presented vision is to throttle or slow down > > the allocators when the system swap is near full and there is no need > > to set swap.max or swap.high. I have the same impression as Shakeel here. The overall information we have here is really scarce. > It's a piece of the puzzle to make memory protection work comprehensively. > You can argue that the fact swap isn't protection based is against the > direction but I find that argument rather facetious as swap is quite > different resource from memory and it's not like I'm saying limits shouldn't > be used at all. There sure still are missing pieces - ie. slowing down on > global depletion, but that doesn't mean swap.high isn't useful. I have asked about the semantic of this know already and didn't really get any real answer. So how does swap.high fit into high limit semantic when it doesn't act as a limit. Considering that we cannot reclaim swap space I find this really hard to grasp. We definitely need more information here! -- Michal Hocko SUSE Labs
