From: "H. Peter Anvin" <hpa@zytor.com>
To: "linux-mm@kvack.org" <linux-mm@kvack.org>, linux-arch@vger.kernel.org
Cc: Suresh Siddha <suresh.b.siddha@intel.com>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
Sam Ravnborg <sam@ravnborg.org>
Subject: PG_uncached, CONFIG_EXTENDED_PAGEFLAGS and !NUMA
Date: Fri, 28 Aug 2009 11:59:00 -0700 [thread overview]
Message-ID: <4A9828F4.4040905@zytor.com> (raw)
Hi all,
I am looking at a patchset by Venkatesh Pallipadi which cleans up a lot
of the corner cases in x86 PAT.
http://marc.info/?i=cover.1247162373.git.venkatesh.pallipadi@intel.com
This patchset pages PG_uncached available to other architectures than
IA64 on an opt-in basis. Unfortunately, it means we run out of page
flags on X86_32+PAE+SPARSEMEM.
Rather than increasing SECTION_SIZE_BITS further, it seems more
reasonable to disable CONFIG_EXTENDED_PAGEFLAGS in this case:
diff --git a/mm/Kconfig b/mm/Kconfig
index c948d4c..fe221c7 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -153,7 +153,7 @@ config MEMORY_HOTREMOVE
#
config PAGEFLAGS_EXTENDED
def_bool y
- depends on 64BIT || SPARSEMEM_VMEMMAP || !NUMA || !SPARSEMEM
+ depends on 64BIT || SPARSEMEM_VMEMMAP || !SPARSEMEM
# Heavily threaded applications may benefit from splitting the mm-wide
Dropping the !NUMA requirement here seems reasonable, since we already
have generic code that handles removing the node number from the page
flags when there are too many.
We could make this an x86-specific change, but the above generic change
would be cleaner in terms of Kconfig complexity. Would people object to
this as a general change?
-hpa
--
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>
reply other threads:[~2009-08-28 18:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4A9828F4.4040905@zytor.com \
--to=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=sam@ravnborg.org \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.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