From: Andy Whitcroft <apw@shadowen.org>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Mel Gorman <mel@csn.ul.ie>, Andy Whitcroft <apw@shadowen.org>
Subject: [RFC PATCH 0/4] Reclaim page capture v2
Date: Wed, 3 Sep 2008 19:44:08 +0100 [thread overview]
Message-ID: <1220467452-15794-1-git-send-email-apw@shadowen.org> (raw)
For sometime we have been looking at mechanisms for improving the availability
of larger allocations under load. One of the options we have explored is
the capturing of pages freed under direct reclaim in order to increase the
chances of free pages coelescing before they are subject to reallocation
by racing allocators.
Following this email is a patch stack implementing page capture during
direct reclaim. It consits of four patches. The first two simply pull
out existing code into helpers for reuse. The third makes buddy's use
of struct page explicit. The fourth contains the meat of the changes,
and its leader contains a much fuller description of the feature.
This update represents a rebase to -mm and incorporates feedback from
KOSAKI Motohiro. It also incorporates an accounting fix which was
preventing some captures.
I have done a lot of comparitive testing with and without this patch
set and in broad brush I am seeing improvements in hugepage allocations
(worst case size) success on all of my test systems. These tests consist
of placing a constant stream of high order allocations on the system,
at varying rates. The results for these various runs are then averaged
to give an overall improvement.
Absolute Effective
x86-64 2.48% 4.58%
powerpc 5.55% 25.22%
x86-64 has a relatively small huge page size and so is always much more
effective at allocating huge pages. Even there we get a measurable
improvement. On powerpc the huge pages are much larger and much harder
to recover. Here we see a full 25% increase in page recovery.
It should be noted that these are worst case testing, and very agressive
taking every possible page in the system.
Against: 2.6.27-rc1-mm1
Comments?
-apw
Changes since V1:
- Incorporates review feedback from KOSAKI Motohiro,
- fixes up accounting when checking watermarks for captured pages,
- rebase 2.6.27-rc1-mm1,
- Incorporates review feedback from Mel.
Andy Whitcroft (4):
pull out the page pre-release and sanity check logic for reuse
pull out zone cpuset and watermark checks for reuse
buddy: explicitly identify buddy field use in struct page
capture pages freed during direct reclaim for allocation by the
reclaimer
include/linux/mm_types.h | 4 +
include/linux/page-flags.h | 6 +
mm/internal.h | 8 ++-
mm/page_alloc.c | 255 ++++++++++++++++++++++++++++++++++++++------
mm/vmscan.c | 115 ++++++++++++++++----
5 files changed, 332 insertions(+), 56 deletions(-)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2008-09-03 18:44 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-03 18:44 Andy Whitcroft [this message]
2008-09-03 18:44 ` [PATCH 1/4] pull out the page pre-release and sanity check logic for reuse Andy Whitcroft
2008-09-04 1:24 ` Rik van Riel
2008-09-05 1:52 ` KOSAKI Motohiro
2008-09-03 18:44 ` [PATCH 2/4] pull out zone cpuset and watermark checks " Andy Whitcroft
2008-09-04 1:24 ` Rik van Riel
2008-09-05 1:52 ` KOSAKI Motohiro
2008-09-03 18:44 ` [PATCH 3/4] buddy: explicitly identify buddy field use in struct page Andy Whitcroft
2008-09-03 20:36 ` Christoph Lameter
2008-09-04 1:25 ` Rik van Riel
2008-09-05 1:52 ` KOSAKI Motohiro
2008-09-03 18:44 ` [PATCH 4/4] capture pages freed during direct reclaim for allocation by the reclaimer Andy Whitcroft
2008-09-03 20:35 ` Christoph Lameter
2008-09-03 20:53 ` Andy Whitcroft
2008-09-03 21:00 ` Christoph Lameter
2008-09-04 6:38 ` Peter Zijlstra
2008-09-04 14:18 ` Christoph Lameter
2008-09-04 8:11 ` KOSAKI Motohiro
2008-09-04 8:58 ` Andy Whitcroft
2008-09-04 7:20 ` Peter Zijlstra
2008-09-04 11:35 ` Andy Whitcroft
2008-09-04 7:59 ` KOSAKI Motohiro
2008-09-04 14:44 ` Andy Whitcroft
2008-09-05 1:52 ` KOSAKI Motohiro
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1220467452-15794-1-git-send-email-apw@shadowen.org \
--to=apw@shadowen.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox