On 10/05/2010 03:53 AM, Michel Lespinasse wrote:
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 ?
I imagine MySQL could show the problem, on a system with so much memory pressure that part of MySQL itself gets swapped out (a slightly too large innodb buffer?). Without your patches, a new database thread can only be created in-between page faults. With your patches, a new thread can be started even while other threads are waiting on page faults. More importantly, multiple threads can start pagein IO simultaneously after memory pressure has let up. This should allow the system to go back to normal performance much faster after a load spike has passed. -- 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>