Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap
From: David Rientjes
Date: Mon Jul 10 2017 - 20:01:33 EST
On Tue, 27 Jun 2017, Tetsuo Handa wrote:
> I wonder why you prefer timeout based approach. Your patch will after all
> set MMF_OOM_SKIP if operations between down_write() and up_write() took
> more than one second. lock_anon_vma_root() from unlink_anon_vmas() from
> free_pgtables() for example calls down_write()/up_write(). unlink_file_vma()
> from free_pgtables() for another example calls down_write()/up_write().
> This means that it might happen that exit_mmap() takes more than one second
> with mm->mmap_sem held for write, doesn't this?
I certainly have no objection to increasing the timeout period or
increasing MAX_OOM_REAP_RETRIES to be substantially higher. All threads
holding mm->mmap_sem should be oom killed and be able to access memory
reserves to make forward progress if they fail to reclaim. If we are
truly blocked on mm->mmap_sem, waiting longer than one second to declare
that seems justifiable to prevent the exact situation you describe.