Messages in this thread | | | Date | Fri, 8 Apr 2022 13:48:08 +0200 | From | Michal Hocko <> | Subject | Re: [PATCH v8] oom_kill.c: futex: Don't OOM reap the VMA containing the robust_list_head |
| |
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
| |