Messages in this thread | | | Date | Mon, 10 Jul 2017 17:01:01 -0700 (PDT) | From | David Rientjes <> | Subject | Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap |
| |
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.
| |