From: Christoph Lameter <clameter@sgi.com>
To: linux-kernel@vger.kernel.org
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: apw@shadowen.org
Cc: linux-mm@kback.org
Subject: [rfc 10/10] Pageflags land grab
Date: Fri, 29 Feb 2008 20:05:44 -0800 [thread overview]
Message-ID: <20080301040622.220638278@sgi.com> (raw)
In-Reply-To: 20080301040534.797979115@sgi.com
[-- Attachment #1: pageflags_land_grab --]
[-- Type: text/plain, Size: 3811 bytes --]
We have enough page flags after vmemmap no longer uses section ids.
Reserve 5 of the 6 saved flags for functionality that is currently
under development in the VM.
The new flags are only available if either of these conditions are met:
1. 64 Bit system. (then we have 8 more free of the 32)
2. !NUMA. In that case 2 bits are needed for the zone
id which leaves 30 page flag bits. Of those we use 24. 6 left.
3. !SPARSEMEM. In that case we use 5 bits of the 30 available
for the node. 1 leftover.
4. SPARSEMEM_VMEMMAP. Case 3 applies.
The remaining case is classic sparsemem with NUMA on a 32 bit platform.
In that case we need to use additional bits from the remaining 25 which
does not allow the use of all 5 extended page flags.
We could deal with that case by only allowing sparsemem vmemmap (if
sparsemem is selected as a model) on 32 bit NUMA platforms.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
---
include/linux/page-flags.h | 32 +++++++++++++++++++++++++++++---
mm/Kconfig | 11 +++++++++++
2 files changed, 40 insertions(+), 3 deletions(-)
Index: linux-2.6/include/linux/page-flags.h
===================================================================
--- linux-2.6.orig/include/linux/page-flags.h 2008-02-29 19:33:01.000000000 -0800
+++ linux-2.6/include/linux/page-flags.h 2008-02-29 19:37:31.000000000 -0800
@@ -81,11 +81,24 @@ enum pageflags {
PG_reserved,
PG_private, /* If pagecache, has fs-private data */
PG_writeback, /* Page is under writeback */
- PG_compound, /* A compound page */
PG_swapcache, /* Swap page: swp_entry_t in private */
PG_mappedtodisk, /* Has blocks allocated on-disk */
PG_reclaim, /* To be reclaimed asap */
PG_buddy, /* Page is free, on buddy lists */
+#ifdef CONFIG_EXTENDED_PAGEFLAGS
+ /*
+ * Page flags that are only available without sparsemem on 32 bit
+ * (sparsemem vmemmap is ok. Flags are always available on 64 bit.
+ */
+ PG_mlock, /* Page cannot be swapped out */
+ PG_pin, /* Page cannot be moved in memory */
+ PG_tail, /* Tail of a compound page */
+ PG_head, /* Head of a compound page */
+ PG_vcompound, /* Compound page is virtually mapped */
+ PG_filebacked, /* Page is backed by an actual disk (not RAM) */
+#else
+ PG_compound, /* A compound page */
+#endif
#if (BITS_PER_LONG > 32)
/*
@@ -245,8 +258,20 @@ static inline void set_page_writeback(st
test_set_page_writeback(page);
}
-TESTPAGEFLAG(Compound, compound)
-__PAGEFLAG(Head, compound)
+#ifdef CONFIG_EXTENDED_PAGEFLAGS
+__PAGEFLAG(Head, head)
+__PAGEFLAG(Tail, tail)
+__PAGEFLAG(Vcompound, vcompound)
+__PAGEFLAG(Mlock, mlock)
+__PAGEFLAG(Pin, pin)
+__PAGEFLAG(FileBacked, filebacked)
+
+static inline int PageCompound(struct page *page)
+{
+ return (page->flags & ((1 << PG_tail) | (1 << PG_head))) != 0;
+}
+
+#else
/*
* PG_reclaim is used in combination with PG_compound to mark the
@@ -274,5 +299,6 @@ static inline void __ClearPageTail(struc
{
page->flags &= ~PG_head_tail_mask;
}
+#endif
#endif /* PAGE_FLAGS_H */
Index: linux-2.6/mm/Kconfig
===================================================================
--- linux-2.6.orig/mm/Kconfig 2008-02-29 19:13:55.000000000 -0800
+++ linux-2.6/mm/Kconfig 2008-02-29 19:37:31.000000000 -0800
@@ -193,3 +193,14 @@ config NR_QUICK
config VIRT_TO_BUS
def_bool y
depends on !ARCH_NO_VIRT_TO_BUS
+
+#
+# I wish we could get rid of this...... The main problem is the page
+# flag use on 32 bit system with NUMA and SPARSEMEM (no sparsemem_vmemmap).
+# Does not really make any sense to use sparsemem there since 32 bit spaces
+# will typically be backed by contiguous RAM these days. So there is nothing
+# sparse there anymore.
+#
+config EXTENDED_PAGEFLAGS
+ def_bool y
+ depends on 64BIT || !SPARSEMEM || !NUMA || SPARSEMEM_VMEMMAP
--
next prev parent reply other threads:[~2008-03-01 4:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-01 4:05 [rfc 00/10] [RFC] Page flags: Saving some, making handling easier etc Christoph Lameter
2008-03-01 4:05 ` [rfc 01/10] Pageflags: Use an enum for the flags Christoph Lameter
2008-03-03 10:09 ` Mel Gorman
2008-03-01 4:05 ` [rfc 02/10] Pageflags: Introduce macros to generate page flag functions Christoph Lameter
2008-03-01 4:05 ` [rfc 03/10] Pageflags: Convert to the use of new macros Christoph Lameter
2008-03-03 10:24 ` Mel Gorman
2008-03-03 18:03 ` Christoph Lameter
2008-03-07 11:13 ` Mel Gorman
2008-03-01 4:05 ` [rfc 04/10] Pageflags: Eliminate PG_readahead Christoph Lameter
2008-03-01 4:05 ` [rfc 05/10] Sparsemem: Vmemmap does not need section bits Christoph Lameter
2008-03-01 4:05 ` [rfc 06/10] Kbuild: Create a way to create preprocessor constants from C expressions Christoph Lameter
2008-03-01 4:05 ` [rfc 07/10] Pageflags: Get rid of FLAGS_RESERVED Christoph Lameter
2008-03-01 16:26 ` Rik van Riel
2008-03-03 17:57 ` Christoph Lameter
2008-03-01 4:05 ` [rfc 08/10] Export NR_MAX_ZONES to the preprocessor Christoph Lameter
2008-03-01 4:05 ` [rfc 09/10] Get rid of __ZONE_COUNT Christoph Lameter
2008-03-01 4:05 ` Christoph Lameter [this message]
2008-03-01 17:21 ` [rfc 10/10] Pageflags land grab Rik van Riel
-- strict thread matches above, loose matches on Subject: below --
2008-03-01 4:07 [rfc 00/10] [RFC] Page flags: Saving some, making handling easier etc Christoph Lameter
2008-03-01 4:08 ` [rfc 10/10] Pageflags land grab Christoph Lameter
2008-03-04 0:04 [rfc 00/10] [Patch] Page flags: Cleanup, reorg and introduce 5 new flags Christoph Lameter
2008-03-04 0:05 ` [rfc 10/10] Pageflags: Land grab Christoph Lameter
2008-03-04 0:05 ` Christoph Lameter
2008-03-04 1:27 ` Andi Kleen
2008-03-04 5:38 ` 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=20080301040622.220638278@sgi.com \
--to=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.