From: Andy Whitcroft <apw@shadowen.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Jon Tollefson <kniht@linux.vnet.ibm.com>,
Mel Gorman <mel@csn.ul.ie>, Nick Piggin <nickpiggin@yahoo.com.au>,
Christoph Lameter <cl@linux-foundation.org>,
Andy Whitcroft <apw@shadowen.org>
Subject: [PATCH 0/2] Fixes for gigantic compounds pages V3
Date: Thu, 23 Oct 2008 15:19:17 +0100 [thread overview]
Message-ID: <1224771559-19363-1-git-send-email-apw@shadowen.org> (raw)
[This update includes the cleanups akpm applied, and moves us to a common
form throughout where gigantic page forms of prep/copy/clear are only
used where the original page size is gigantic. These should trigger
the minimum overall cost for non-gigantic cases. It also brings the two
patches into one series for easier tracking.]
During stress testing of the gigantic pages in 2.6.27 threw up some more
places where the hugepage support assumes the mem_map is contigious.
The buddy allocator does not guarentee that the memory map is contigious,
and in some memory models it is not; notably with SPARSMEM without
VMEMMAP enabled.
These have been round a couple of times, and I think most of the objections
and comments are included. The one outstanding was why we needed to fix
it at all as people could use VMEMMAP. What is comes down to is that
there are legitimate combinations of features, such as memory hot remove,
which require SPARSMEM without VMEMMAP. With that combination enabled
then any use of gigantic pages will skip off the end of the mem_map
segments and read random memory, with all the associated risks.
This patch set introduces some new iterators for the mem_map which know how
to follow across discontiguities. It then uses those to provide gigantic
versions of copy_huge_page, clear_huge_page, and prep_compound_page.
This patch set effectivly backs out the changes to prep_compound_page
removing any potential performance issues.
Please consider these patches for -mm. It is likely arguable these are
also stable candidates for 2.6.27 once they have had some run time.
Thanks to Jon Tollefson for his help testing previous versions of these
patches.
-apw
Andy Whitcroft (2):
hugetlbfs: handle pages higher order than MAX_ORDER
hugetlb: pull gigantic page initialisation out of the default path
mm/hugetlb.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++--
mm/internal.h | 29 +++++++++++++++++++++++++++++
mm/page_alloc.c | 28 +++++++++++++++++++++-------
3 files changed, 97 insertions(+), 9 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-10-23 14:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-23 14:19 Andy Whitcroft [this message]
2008-10-23 14:19 ` [PATCH 1/2] hugetlbfs: handle pages higher order than MAX_ORDER Andy Whitcroft
2008-10-23 14:19 ` [PATCH 2/2] hugetlb: pull gigantic page initialisation out of the default path Andy Whitcroft
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=1224771559-19363-1-git-send-email-apw@shadowen.org \
--to=apw@shadowen.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=kniht@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=nickpiggin@yahoo.com.au \
/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