| From: |
| Michel Lespinasse <walken@google.com> |
| To: |
| linux-mm@kvack.org, Linus Torvalds <torvalds@linux-foundation.org>,
Ying Han <yinghan@google.com> |
| Subject: |
| [PATCH 0/3] V2: Reduce mmap_sem hold times during file backed page faults |
| Date: |
| Tue, 5 Oct 2010 00:53:32 -0700 |
| Message-ID: |
| <1286265215-9025-1-git-send-email-walken@google.com> |
| Cc: |
| linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Rik van Riel <riel@redhat.com>,
Nick Piggin <npiggin@kernel.dk>,
Peter Zijlstra <peterz@infradead.org> |
| Archive-link: |
| Article, Thread
|
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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/