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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
