|| ||Mel Gorman <firstname.lastname@example.org> |
|| ||Alexey Lyahkov <email@example.com>,
Andrew Perepechko <firstname.lastname@example.org>,
Robin Dong <email@example.com> |
|| ||[PATCH 0/4] Obey mark_page_accessed hint given by filesystems v2 |
|| ||Mon, 13 May 2013 11:21:18 +0100|
|| ||Theodore Tso <firstname.lastname@example.org>,
Andrew Morton <email@example.com>,
Hugh Dickins <firstname.lastname@example.org>,
Rik van Riel <email@example.com>,
Johannes Weiner <firstname.lastname@example.org>,
Bernd Schubert <email@example.com>,
David Howells <firstname.lastname@example.org>,
Trond Myklebust <Trond.Myklebust@netapp.com>,
Linux-mm <email@example.com>, Mel Gorman <firstname.lastname@example.org>|
|| ||Article, Thread
This series is in need of Tested-by's and some reviewing before it can be
pushed anywhere. The performance of the tests I ran were not sensitive
to the premature reclaim of buffer pages although I was able to show
the average age of buffer pages is now higher as expected. Also note the
comments I make about the average age of file pages versus buffer pages
at the end of this mail that I'd like filesystem people to think about.
Changelog since V1
o Add tracepoint to model age of page types (mel)
Andrew Perepechko reported a problem whereby pages are being prematurely
evicted as the mark_page_accessed() hint is ignored for pages that are
currently on a pagevec -- http://www.spinics.net/lists/linux-ext4/msg37340.html .
Alexey Lyahkov and Robin Dong have also reported problems recently that
could be due to hot pages reaching the end of the inactive list too quickly
and be reclaimed.
Rather than addressing this on a per-filesystem basis, this series aims
to fix the mark_page_accessed() interface by deferring what LRU a page
is added to pagevec drain time and allowing mark_page_accessed() to call
SetPageActive on a pagevec page.
Patch 1 adds two tracepoints for LRU page activation and insertion. Using
these processes it's possible to build a model of pages in the
LRU that can be processed offline.
Patch 2 defers making the decision on what LRU to add a page to until when
the pagevec is drained.
Patch 3 searches the local pagevec for pages to mark PageActive on
mark_page_accessed. The changelog explains why only the local
pagevec is examined.
Patch 4 tidies up the API.
postmark, a dd-based test and fs-mark both single and threaded mode were
run but none of them showed any performance degradation or gain as a result
of the patch.
Using patch 1, I built a *very* basic model of the LRU to examine
offline what the average age of different page types on the LRU were in
milliseconds. Of course, capturing the trace distorts the test as it's
written to local disk but it does not matter for the purposes of this test.
The average age of pages in milliseconds were
Average age mapped anon: 1454 1855
Average age mapped file: 127841 143755
Average age unmapped anon: 85 157
Average age unmapped file: 73633 39368
Average age unmapped buffers: 74054 116636
The LRU activity was mostly files which you'd expect for a dd-based
workload. Note that the average age of buffer pages is increased by the
series and it is expected this is due to the fact that the buffer pages are
now getting added to the active list when drained from the pagevecs. Note
that the average age of the unmapped file data is decreased as they are
still added to the inactive list and are reclaimed before the buffers. There
is no guarantee this is a universal win for all workloads and it would be
nice if the filesystem people gave some thought as to whether this decision
is generally a win or a loss.
fs/cachefiles/rdwr.c | 30 ++++----------
fs/nfs/dir.c | 7 +---
include/linux/pagevec.h | 34 +---------------
include/trace/events/pagemap.h | 89 ++++++++++++++++++++++++++++++++++++++++++
mm/swap.c | 82 +++++++++++++++++++++++++-------------
5 files changed, 154 insertions(+), 88 deletions(-)
create mode 100644 include/trace/events/pagemap.h
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/