From: Christoph Lameter <clameter@sgi.com>
To: akpm@linux-foundation.org
Cc: linux-mm@kvack.org
Subject: [00/11] Virtualizable Compound Page Support V5
Date: Tue, 29 Apr 2008 21:42:51 -0700 [thread overview]
Message-ID: <20080430044251.266380837@sgi.com> (raw)
Allocations of larger pages are not reliable in Linux. If larger
pages have to be allocated then one faces various choices of allowing
graceful fallback or using vmalloc with a performance penalty due
to the use of a page table. Virtualizable Compound Pages are
a simple solution out of this dilemma.
A virtualizable compound allocation means that there will be first
an attempt to satisfy the request with physically contiguous memory
through a traditional compound page. If that is not possible then
virtually contiguous memory will be used for the page.
This has two advantages:
1. Current uses of vmalloc can be converted to request for virtualizable
compounds instead. In most cases physically contiguous memory can be
used which avoids the vmalloc performance penalty. See f.e. the
e1000 driver patch.
2. Uses of higher order allocations (stacks, buffers etc) can be
converted to use virtualizable compounds instead. Physically contiguous
memory will still be used for those higher order allocs in general
but the system can degrade to the use of vmalloc should memory
become heavily fragmented.
There is a compile time option to switch on fallback for
testing purposes. Virtually mapped memory may behave differently
and the CONFIG_VIRTUALIZE_ALWAYS option can be used ensure that the code is
tested to deal with virtualized compound page.
This patchset contains first of all the core pieces to make virtualizable
compound pages possible and then a set of example uses of virtualizable
compound pages.
V4->V5
- Cleanup various portions
- Simplify code
- Complete documentation
- Limit the number of example uses.
V3->V4:
- Drop fallback for IA64 stack (arches with software tlb handlers
could get into deep trouble if a tlb needs to be installed
for the stack that is needed by the tlb fault handler).
- Drop ehash_lock vcompound patch.
V2->V3:
- Put the code into mm/vmalloc.c and leave the page allocator alone.
- Add a series of examples where virtual compound pages can be used.
- Diffed on top of the page flags and the vmalloc info patches
already in mm.
- Simplify things by omitting some of the more complex code
that used to be in there.
V1->V2
- Remove some cleanup patches and the SLUB patches from this set.
- Transparent vcompound support through page_address() and
virt_to_head_page().
- Additional use cases.
- Factor the code better for an easier read
- Add configurable stack size.
- Follow up on various suggestions made for V1
RFC->V1
- Complete support for all compound functions for virtual compound pages
(including the compound_nth_page() necessary for LBS mmap support)
- Fix various bugs
- Fix i386 build
--
--
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-04-30 4:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-30 4:42 Christoph Lameter [this message]
2008-04-30 4:42 ` [01/11] vmalloc: Return page array on vunmap Christoph Lameter
2008-04-30 4:42 ` [02/11] vcompound: pageflags: Add PageVcompound() Christoph Lameter
2008-04-30 4:42 ` [03/11] vmallocinfo: Support display of virtualized compound pages Christoph Lameter
2008-04-30 4:42 ` [04/11] vcompound: Core piece for virtualizable compound page allocation Christoph Lameter
2008-04-30 4:42 ` [05/11] vcompound: Debugging aid Christoph Lameter
2008-04-30 4:42 ` [06/11] sparsemem: Use virtualizable compound page Christoph Lameter
2008-04-30 4:42 ` [07/11] vcompound: bit waitqueue support Christoph Lameter
2008-04-30 4:42 ` [08/11] crypto: Use virtualizable compounds for temporary order 2 allocation Christoph Lameter
2008-04-30 4:43 ` [09/11] slub: Use virtualizable compound for buffer Christoph Lameter
2008-04-30 4:43 ` [10/11] vcompound: Fallback for zone wait table Christoph Lameter
2008-04-30 4:43 ` [11/11] e1000: Avoid vmalloc through virtualizable compound page Christoph Lameter
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=20080430044251.266380837@sgi.com \
--to=clameter@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
/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