On Thu 21-06-18 20:27:41, Tetsuo Handa wrote:
[....]
> On 2018/06/21 16:31, Michal Hocko wrote:
> > On Wed 20-06-18 15:36:45, David Rientjes wrote:
> > [...]
> >> That makes me think that "oom_notify_list" isn't very intuitive: it can
> >> free memory as a last step prior to oom kill. OOM notify, to me, sounds
> >> like its only notifying some callbacks about the condition. Maybe
> >> oom_reclaim_list and then rename this to oom_reclaim_pages()?
> >
> > Yes agreed and that is the reason I keep saying we want to get rid of
> > this yet-another-reclaim mechanism. We already have shrinkers which are
> > the main source of non-lru pages reclaim. Why do we even need
> > oom_reclaim_pages? What is fundamentally different here? Sure those
> > pages should be reclaimed as the last resort but we already do have
> > priority for slab shrinking so we know that the system is struggling
> > when reaching the lowest priority. Isn't that enough to express the need
> > for current oom notifier implementations?
> >
>
> Even if we update OOM notifier users to use shrinker hooks, they will need a
> subtle balance which is currently achieved by mutex_trylock(&oom_lock).
No they do not. They do not want to rely on an unrelated locks to work
properly. That is completely wrong design. We do want locks to protect
specific data rather than code.
> Removing OOM notifier is not doable right now.
I haven't heard any technical argument why.
> It is not suitable as a regression
> fix for commit 27ae357fa82be5ab ("mm, oom: fix concurrent munlock and oom reaper
> unmap, v3").
What is the regression?
> What we could afford for this regression is
> https://patchwork.kernel.org/patch/9842889/ which is exactly what you suggested
> in a thread at https://www.spinics.net/lists/linux-mm/msg117896.html .
--
Michal Hocko
SUSE Labs
