From: Christoph Lameter <clameter@sgi.com>
To: linux-kernel@vger.kernel.org
Cc: ak@suse.com, holt@sgi.com, linux-ia64@vger.kernel.org,
Christoph Lameter <clameter@sgi.com>,
mpm@selenic.com
Subject: [QUICKLIST 0/6] Arch independent quicklists V1
Date: Sun, 11 Mar 2007 02:09:23 +0000 [thread overview]
Message-ID: <20070311020923.19905.49260.sendpatchset@schroedinger.engr.sgi.com> (raw)
This patchset introduces an arch independent framework to handle lists
of recently used page table pages.
Page table pages have the characteristics that they are typically zero
or in a known state when they are freed. This is usually the exactly
same state as needed after allocation. So it makes sense to build a list
of freed page table pages and then consume the pages already in use
first. Those pages have already been initialized correctly (thus no
need to zero them) and are likely already cached in such a way that
the MMU can use them most effectively.
Such an implementation already exits for ia64. If I remember correctly
it was done by Robin Holt. Howver, that implementation did not support
constructors and destructors as needed by i386 / x86_64. It also only
supported a single quicklist. The implementation here has constructor
and destructor support as well as the ability for an arch to specify
how many quicklists are needed.
Quicklists are defined by an arch defining the necessary number
of quicklists in arch/<arch>/Kconfig. F.e. i386 needs two and thus
has
config NR_QUICK
int
default 2
If an arch has requested quicklist support then pages can be allocated
from the quicklist (or from the page allocator if the quicklist is
empty) via:
quicklist_alloc(<quicklist-nr>, <gfpflags>, <constructor>)
Page table pages can be freed using:
quicklist_free(<quicklist-nr>, <destructor>, <page>)
Pages must have a definite state after allocation and before
they are freed. If no constructor is specified then pages
will be zeroed on allocation and must be zeroed before they are
freed.
If a constructor is used then the constructor will establish
a definite page state. F.e. the i386 and x86_64 pgd constructors
establish certain mappings.
Constructors and destructors can also be used to track the pages.
i386 and x86_64 use a list of pgds in order to be able to dynamically
update standard mappings.
6 patches follow this message:
[QUICKLIST 1/6] Extract quicklist implementation from IA64
[QUICKLIST 2/6] i386: quicklist support
[QUICKLIST 3/6] i386: Use standard list manipulators for pgd_list
[QUICKLIST 4/6] x86_64: Single quicklist
[QUICKLIST 5/6] x86_64: Separate quicklist for pgds
[QUICKLIST 6/6] slub: remove special casing for PAGE_SIZE slabs
next reply other threads:[~2007-03-11 2:09 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-11 2:09 Christoph Lameter [this message]
2007-03-11 2:09 ` [QUICKLIST 1/6] Extract quicklist implementation from IA64 Christoph Lameter
2007-03-11 2:09 ` [QUICKLIST 2/6] i386: quicklist support Christoph Lameter
2007-03-11 3:22 ` William Lee Irwin III
2007-03-11 2:09 ` [QUICKLIST 3/6] i386: Use standard list manipulators for pgd_list Christoph Lameter
2007-03-11 2:09 ` [QUICKLIST 4/6] x86_64: Single Quicklist Christoph Lameter
2007-03-11 7:54 ` Andi Kleen
2007-03-11 16:44 ` Christoph Lameter
2007-03-14 19:49 ` Mel Gorman
2007-03-11 2:09 ` [QUICKLIST 5/6] x86_64: Separate quicklist for pgds Christoph Lameter
2007-03-11 2:09 ` [QUICKLIST 6/6] slub: remove special casing for PAGE_SIZE slabs Christoph Lameter
2007-03-11 20:59 ` [QUICKLIST 0/6] Arch independent quicklists V1 David Miller
2007-03-12 11:12 ` Christoph Lameter
2007-03-12 11:23 ` David Miller
2007-03-12 15:52 ` Robin Holt
2007-03-12 22:51 ` David Miller
2007-03-13 0:37 ` Paul Mackerras
2007-03-13 1:38 ` Christoph Lameter
2007-03-13 2:26 ` David Miller
2007-03-13 2:32 ` David Miller
2007-03-15 7:23 ` Andrew Morton
2007-03-15 7:31 ` David Miller
2007-03-15 7:40 ` Andrew Morton
2007-03-14 0:41 ` William Lee Irwin III
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=20070311020923.19905.49260.sendpatchset@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=ak@suse.com \
--cc=holt@sgi.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
/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