From: Andi Kleen <andi@firstfloor.org>
To: akpm@osdl.org, torvalds@osdl.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, balbir@linux.vnet.ibm.com
Subject: [PATCH] Document huge memory/cache overhead of memory controller in Kconfig
Date: Wed, 20 Feb 2008 13:23:38 +0100 [thread overview]
Message-ID: <20080220122338.GA4352@basil.nowhere.org> (raw)
Document huge memory/cache overhead of memory controller in Kconfig
I was a little surprised that 2.6.25-rc* increased struct page for the memory
controller. At least on many x86-64 machines it will not fit into a single
cache line now anymore and also costs considerable amounts of RAM.
At earlier review I remembered asking for a external data structure for this.
It's also quite unobvious that a innocent looking Kconfig option with a
single line Kconfig description has such a negative effect.
This patch attempts to document these disadvantages at least so that users
configuring their kernel can make a informed decision.
Cc: balbir@linux.vnet.ibm.com
Signed-off-by: Andi Kleen <ak@suse.de>
Index: linux/init/Kconfig
===================================================================
--- linux.orig/init/Kconfig
+++ linux/init/Kconfig
@@ -394,6 +394,14 @@ config CGROUP_MEM_CONT
Provides a memory controller that manages both page cache and
RSS memory.
+ Note that setting this option increases fixed memory overhead
+ associated with each page of memory in the system by 4/8 bytes
+ and also increases cache misses because struct page on many 64bit
+ systems will not fit into a single cache line anymore.
+
+ Only enable when you're ok with these trade offs and really
+ sure you need the memory controller.
+
config PROC_PID_CPUSET
bool "Include legacy /proc/<pid>/cpuset file"
depends on CPUSETS
WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <andi@firstfloor.org>
To: akpm@osdl.org, torvalds@osdl.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, balbir@linux.vnet.ibm.com
Subject: [PATCH] Document huge memory/cache overhead of memory controller in Kconfig
Date: Wed, 20 Feb 2008 13:23:38 +0100 [thread overview]
Message-ID: <20080220122338.GA4352@basil.nowhere.org> (raw)
Document huge memory/cache overhead of memory controller in Kconfig
I was a little surprised that 2.6.25-rc* increased struct page for the memory
controller. At least on many x86-64 machines it will not fit into a single
cache line now anymore and also costs considerable amounts of RAM.
At earlier review I remembered asking for a external data structure for this.
It's also quite unobvious that a innocent looking Kconfig option with a
single line Kconfig description has such a negative effect.
This patch attempts to document these disadvantages at least so that users
configuring their kernel can make a informed decision.
Cc: balbir@linux.vnet.ibm.com
Signed-off-by: Andi Kleen <ak@suse.de>
Index: linux/init/Kconfig
===================================================================
--- linux.orig/init/Kconfig
+++ linux/init/Kconfig
@@ -394,6 +394,14 @@ config CGROUP_MEM_CONT
Provides a memory controller that manages both page cache and
RSS memory.
+ Note that setting this option increases fixed memory overhead
+ associated with each page of memory in the system by 4/8 bytes
+ and also increases cache misses because struct page on many 64bit
+ systems will not fit into a single cache line anymore.
+
+ Only enable when you're ok with these trade offs and really
+ sure you need the memory controller.
+
config PROC_PID_CPUSET
bool "Include legacy /proc/<pid>/cpuset file"
depends on CPUSETS
--
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-02-20 12:23 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-20 12:23 Andi Kleen [this message]
2008-02-20 12:23 ` [PATCH] Document huge memory/cache overhead of memory controller in Kconfig Andi Kleen
2008-02-20 12:52 ` Balbir Singh
2008-02-20 12:52 ` Balbir Singh
2008-02-20 15:00 ` John Stoffel
2008-02-20 15:00 ` John Stoffel
2008-02-20 15:20 ` Balbir Singh
2008-02-20 15:20 ` Balbir Singh
2008-02-20 15:49 ` Jan Engelhardt
2008-02-20 15:49 ` Jan Engelhardt
2008-02-20 16:10 ` John Stoffel
2008-02-20 16:10 ` John Stoffel
2008-02-20 16:15 ` Balbir Singh
2008-02-20 16:15 ` Balbir Singh
2008-02-20 17:00 ` Andi Kleen
2008-02-20 17:00 ` Andi Kleen
2008-02-21 6:49 ` KAMEZAWA Hiroyuki
2008-02-21 6:49 ` KAMEZAWA Hiroyuki
2008-02-21 6:52 ` Balbir Singh
2008-02-21 6:52 ` Balbir Singh
2008-02-20 18:19 ` Pavel Machek
2008-02-20 18:19 ` Pavel Machek
2008-02-20 18:28 ` Jan Engelhardt
2008-02-20 18:28 ` Jan Engelhardt
2008-02-20 18:51 ` Pavel Machek
2008-02-20 18:51 ` Pavel Machek
2008-02-21 14:46 ` KOSAKI Motohiro
2008-02-21 14:46 ` KOSAKI Motohiro
2008-02-21 14:52 ` Balbir Singh
2008-02-21 14:52 ` Balbir Singh
2008-02-21 23:55 ` Pavel Machek
2008-02-21 23:55 ` Pavel Machek
2008-02-22 3:09 ` KOSAKI Motohiro
2008-02-22 3:09 ` KOSAKI Motohiro
2008-02-20 16:15 ` John Stoffel
2008-02-20 16:15 ` John Stoffel
2008-02-20 16:54 ` Ray Lee
2008-02-20 16:54 ` Ray Lee
2008-02-20 16:57 ` Andi Kleen
2008-02-20 16:57 ` Andi Kleen
2008-02-21 4:35 ` Nick Piggin
2008-02-21 4:35 ` Nick Piggin
2008-02-21 5:06 ` Balbir Singh
2008-02-21 5:06 ` Balbir Singh
[not found] ` <200802211622.51751.nickpiggin@yahoo.com.au>
2008-02-21 5:46 ` Balbir Singh
2008-02-21 5:46 ` Balbir Singh
2008-02-21 10:44 ` Andi Kleen
2008-02-21 10:44 ` Andi Kleen
2008-02-22 4:41 ` Balbir Singh
2008-02-22 4:41 ` Balbir Singh
2008-02-22 9:51 ` Andi Kleen
2008-02-22 9:51 ` Andi Kleen
2008-02-22 12:14 ` Balbir Singh
2008-02-22 12:14 ` Balbir Singh
2008-02-22 13:00 ` Andi Kleen
2008-02-22 13:00 ` Andi Kleen
2008-02-22 15:47 ` Balbir Singh
2008-02-22 15:47 ` Balbir Singh
2008-02-21 10:37 ` Andi Kleen
2008-02-21 10:37 ` Andi Kleen
2008-02-21 11:03 ` Balbir Singh
2008-02-21 11:03 ` Balbir Singh
2008-02-22 6:59 ` KAMEZAWA Hiroyuki
2008-02-22 6:59 ` KAMEZAWA Hiroyuki
2008-02-22 7:06 ` Balbir Singh
2008-02-22 7:06 ` Balbir Singh
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=20080220122338.GA4352@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=akpm@osdl.org \
--cc=balbir@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@osdl.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 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.