Linus, I would appreciate your comments on this since you shot down the previous proposal. I hope you'll find this approach is sane, but I would be interested to hear if you have specific objections. mmap_sem is very coarse grained (per process) and has long read-hold times (disk latencies); this breaks down rapidly for workloads that use both read and write mmap_sem acquires. This short patch series tries to reduce mmap_sem hold times when faulting in file backed VMAs. First patch creates a single place to lock the page in filemap_fault(). There should be no behavior differences. Second patch modifies that lock_page() so that, if trylock_page() fails, we consider releasing the mmap_sem while waiting for page to be unlocked. This is controlled by a new FAULT_FLAG_RELEASE flag. If the mmap_sem gets released, we return the VM_FAULT_RELEASED status; the caller is then expected to re-acquire mmap_sem and retry the page fault. Chances are that the same page will be accessed and will now be unlocked, so the mmap_sem hold time will be short. Michel Lespinasse (2): Unique path for locking page in filemap_fault() Release mmap_sem when page fault blocks on disk transfer. arch/x86/mm/fault.c | 35 ++++++++++++++++++++++++++--------- include/linux/mm.h | 2 ++ mm/filemap.c | 38 +++++++++++++++++++++++++++++--------- mm/memory.c | 3 ++- 4 files changed, 59 insertions(+), 19 deletions(-) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>