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? > -- > Michal Hocko > SUSE Labs > > -- > You received this message because you are subscribed to the Google Groups "kernel-team" group. > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@xxxxxxxxxxx. >
