On Fri 08-04-22 07:26:07, Nico Pache wrote: [...] > Ok so if i understand that correctly, delaying can have some ugly effects and > kinda breaks the initial purpose of the OOM reaper? No, not really. The primary objective of the oom_reaper is to _guaratee_ a forward progress. It is not really meant to be an optimization to respond to the oom killer faster. The reason the oom_reaper is kicked off right away is because that was the simplest implementation. > I personally don't like the delay approach. Especially if we have a better one > we know is working, and that doesnt add regressions. Well, I would say that handling futex case more gracefully would be preferable but my understanding is that this is not all that easy. I am far from being a futex expert so I will leave that up to Thomas and Peter. On the other hand delaying oom_reaper is rather straightforward and I do not think there is a big risk of regressions. Any QoS during OOM is simply out of the window and the main purpose of the reaper will be preserved with a timeout as well. I also do agree with Thomas that this would cover 99% of cases. > If someone can prove to me the private lock case, I'd be more willing to bite. > > Thanks for all the OOM context :) Welcome. The oom handling is a maze and it is really easy to miss all the subtlety and conflicting requirements that are applied here. -- Michal Hocko SUSE Labs
