This is the second iteration of our change dropping mmap_sem when a disk access occurs during a page fault to a file backed VMA. Changes since V1: - Cleaned up 'Retry page fault when blocking on disk transfer' applying linus's suggestions - Added 'access_error API cleanup' Tests: - microbenchmark: thread A mmaps a large file and does random read accesses to the mmaped area - achieves about 55 iterations/s. Thread B does mmap/munmap in a loop at a separate location - achieves 55 iterations/s before, 15000 iterations/s after. - We are seeing related effects in some applications in house, which show significant performance regressions when running without this change. - I am looking for a microbenchmark to expose the worst case overhead of the page fault retry. Would FIO be a good match for that use ? Michel Lespinasse (3): filemap_fault: unique path for locking page Retry page fault when blocking on disk transfer. access_error API cleanup arch/x86/mm/fault.c | 44 +++++++++++++++++++++++++++++--------------- include/linux/mm.h | 2 ++ mm/filemap.c | 41 ++++++++++++++++++++++++++++++++--------- mm/memory.c | 3 ++- 4 files changed, 65 insertions(+), 25 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>