On Thu 11-04-19 12:56:32, Suren Baghdasaryan wrote: > On Thu, Apr 11, 2019 at 11:19 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > On Thu 11-04-19 09:47:31, Suren Baghdasaryan wrote: > > [...] > > > > I would question whether we really need this at all? Relying on the exit > > > > speed sounds like a fundamental design problem of anything that relies > > > > on it. > > > > > > Relying on it is wrong, I agree. There are protections like allocation > > > throttling that we can fall back to stop memory depletion. However > > > having a way to free up resources that are not needed by a dying > > > process quickly would help to avoid throttling which hurts user > > > experience. > > > > I am not opposing speeding up the exit time in general. That is a good > > thing. Especially for a very large processes (e.g. a DB). But I do not > > really think we want to expose an API to control this specific aspect. > > Great! Thanks for confirming that the intent is not worthless. > There were a number of ideas floating both internally and in the 2/2 > of this patchset. I would like to get some input on which > implementation would be preferable. From your answer sounds like you > think it should be a generic feature, should not require any new APIs > or hints from the userspace and should be conducted for all kills > unconditionally (irrespective of memory pressure, who is waiting for > victim's death, etc.). Do I understand correctly that this would be > the preferred solution? Yes, I think the general tear down solution is much more preferable than a questionable API. How that solution should look like is an open question. I am not sure myself to be honest. -- Michal Hocko SUSE Labs
