From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrea Arcangeli <aarcange@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: linux-next: manual merge of the cleancache tree with Linus' tree
Date: Sat, 15 Jan 2011 12:44:51 +1100 [thread overview]
Message-ID: <20110115124451.19c32122.sfr@canb.auug.org.au> (raw)
Hi Dan,
Today's linux-next merge of the cleancache tree got a conflict in
mm/Kconfig between various transparent huge page commits from Linus' tree
and commit 83137a5649ec8a0bb769c68024b0532733087482 ("mm: cleancache core
ops functions and config") from the cleancache tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc mm/Kconfig
index 3ad483b,9ee0751..0000000
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@@ -302,48 -302,24 +302,70 @@@ config NOMMU_INITIAL_TRIM_EXCES
See Documentation/nommu-mmap.txt for more information.
+config TRANSPARENT_HUGEPAGE
+ bool "Transparent Hugepage Support"
+ depends on X86 && MMU
+ select COMPACTION
+ help
+ Transparent Hugepages allows the kernel to use huge pages and
+ huge tlb transparently to the applications whenever possible.
+ This feature can improve computing performance to certain
+ applications by speeding up page faults during memory
+ allocation, by reducing the number of tlb misses and by speeding
+ up the pagetable walking.
+
+ If memory constrained on embedded, you may want to say N.
+
+choice
+ prompt "Transparent Hugepage Support sysfs defaults"
+ depends on TRANSPARENT_HUGEPAGE
+ default TRANSPARENT_HUGEPAGE_ALWAYS
+ help
+ Selects the sysfs defaults for Transparent Hugepage Support.
+
+ config TRANSPARENT_HUGEPAGE_ALWAYS
+ bool "always"
+ help
+ Enabling Transparent Hugepage always, can increase the
+ memory footprint of applications without a guaranteed
+ benefit but it will work automatically for all applications.
+
+ config TRANSPARENT_HUGEPAGE_MADVISE
+ bool "madvise"
+ help
+ Enabling Transparent Hugepage madvise, will only provide a
+ performance improvement benefit to the applications using
+ madvise(MADV_HUGEPAGE) but it won't risk to increase the
+ memory footprint of applications without a guaranteed
+ benefit.
+endchoice
+
+#
+# UP and nommu archs use km based percpu allocator
+#
+config NEED_PER_CPU_KM
+ depends on !SMP
+ bool
+ default y
++
+ config CLEANCACHE
+ bool "Enable cleancache pseudo-RAM driver to cache clean pages"
+ default y
+ help
+ Cleancache can be thought of as a page-granularity victim cache
+ for clean pages that the kernel's pageframe replacement algorithm
+ (PFRA) would like to keep around, but can't since there isn't enough
+ memory. So when the PFRA "evicts" a page, it first attempts to put
+ it into a synchronous concurrency-safe page-oriented pseudo-RAM
+ device (such as Xen's Transcendent Memory, aka "tmem") which is not
+ directly accessible or addressable by the kernel and is of unknown
+ (and possibly time-varying) size. And when a cleancache-enabled
+ filesystem wishes to access a page in a file on disk, it first
+ checks cleancache to see if it already contains it; if it does,
+ the page is copied into the kernel and a disk access is avoided.
+ When a pseudo-RAM device is available, a significant I/O reduction
+ may be achieved. When none is available, all cleancache calls
+ are reduced to a single pointer-compare-against-NULL resulting
+ in a negligible performance hit.
+
+ If unsure, say Y to enable cleancache
next reply other threads:[~2011-01-15 1:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-15 1:44 Stephen Rothwell [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-03-24 2:55 linux-next: manual merge of the cleancache tree with Linus' tree Stephen Rothwell
2011-03-24 3:56 ` Andrew Morton
2011-03-24 5:38 ` Minchan Kim
2011-03-24 5:58 ` Minchan Kim
2011-03-24 6:42 ` Andrew Morton
2011-03-24 15:37 ` Dan Magenheimer
2011-04-14 21:04 ` Dan Magenheimer
2011-02-14 6:17 Stephen Rothwell
2011-01-14 1:12 Stephen Rothwell
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=20110115124451.19c32122.sfr@canb.auug.org.au \
--to=sfr@canb.auug.org.au \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dan.magenheimer@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).