linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave@linux.vnet.ibm.com>
To: linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, lnxninja@linux.vnet.ibm.com,
	Dave Hansen <dave@linux.vnet.ibm.com>
Subject: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation
Date: Tue, 14 Sep 2010 16:47:14 -0700	[thread overview]
Message-ID: <20100914234714.8AF506EA@kernel.beaverton.ibm.com> (raw)


There seems to be an epidemic spreading around.  People get the idea
in their heads that the kernel caches are evil.  They eat too much
memory, and there's no way to set a size limit on them!  Stupid
kernel!

There is plenty of anecdotal evidence and a load of blog posts
suggesting that using "drop_caches" periodically keeps your system
running in "tip top shape".  I do not think that is true.

If we are not shrinking caches effectively, then we have real bugs.
Using drop_caches will simply mask the bugs and make them harder
to find, but certainly does not fix them, nor is it an appropriate
"workaround" to limit the size of the caches.

It's a great debugging tool, and is really handy for doing things
like repeatable benchmark runs.  So, add a bit more documentation
about it, and add a WARN_ONCE().  Maybe the warning will scare
some sense into people.


Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
---

 linux-2.6.git-dave/Documentation/sysctl/vm.txt |   14 ++++++++++++--
 linux-2.6.git-dave/fs/drop_caches.c            |    2 ++
 2 files changed, 14 insertions(+), 2 deletions(-)

diff -puN Documentation/sysctl/vm.txt~update-drop_caches-documentation Documentation/sysctl/vm.txt
--- linux-2.6.git/Documentation/sysctl/vm.txt~update-drop_caches-documentation	2010-09-14 15:30:19.000000000 -0700
+++ linux-2.6.git-dave/Documentation/sysctl/vm.txt	2010-09-14 16:40:58.000000000 -0700
@@ -145,8 +145,18 @@ To free dentries and inodes:
 To free pagecache, dentries and inodes:
 	echo 3 > /proc/sys/vm/drop_caches
 
-As this is a non-destructive operation and dirty objects are not freeable, the
-user should run `sync' first.
+This is a non-destructive operation and will not free any dirty objects.
+To increase the number of objects freed by this operation, the user may run
+`sync' prior to writing to /proc/sys/vm/drop_caches.  This will minimize the
+number of dirty objects on the system and create more candidates to be
+dropped.
+
+This file is not a means to control the growth of the various kernel caches
+(inodes, dentries, pagecache, etc...)  These objects are automatically
+reclaimed by the kernel when memory is needed elsewhere on the system.
+
+Outside of a testing or debugging environment, use of
+/proc/sys/vm/drop_caches is not recommended.
 
 ==============================================================
 
diff -puN fs/drop_caches.c~update-drop_caches-documentation fs/drop_caches.c
--- linux-2.6.git/fs/drop_caches.c~update-drop_caches-documentation	2010-09-14 15:44:29.000000000 -0700
+++ linux-2.6.git-dave/fs/drop_caches.c	2010-09-14 15:58:31.000000000 -0700
@@ -47,6 +47,8 @@ int drop_caches_sysctl_handler(ctl_table
 {
 	proc_dointvec_minmax(table, write, buffer, length, ppos);
 	if (write) {
+		WARN_ONCE(1, "kernel caches forcefully dropped, "
+			     "see Documentation/sysctl/vm.txt\n");
 		if (sysctl_drop_caches & 1)
 			iterate_supers(drop_pagecache_sb, NULL);
 		if (sysctl_drop_caches & 2)
diff -puN include/linux/kernel.h~update-drop_caches-documentation include/linux/kernel.h
diff -puN drivers/pci/intel-iommu.c~update-drop_caches-documentation drivers/pci/intel-iommu.c
diff -puN drivers/pci/dmar.c~update-drop_caches-documentation drivers/pci/dmar.c
_

--
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:[~2010-09-14 23:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-14 23:47 Dave Hansen [this message]
2010-09-15  4:33 ` KAMEZAWA Hiroyuki
2010-09-15  4:53   ` KOSAKI Motohiro
2010-09-15  6:14     ` Dave Hansen
2010-09-15 18:37       ` Eric W. Biederman
2010-09-15 19:27         ` Dave Hansen
2010-09-15 21:34           ` Eric W. Biederman
2010-09-15 19:24   ` Tim Pepper
2010-09-16  0:12     ` KAMEZAWA Hiroyuki
2010-09-16  1:21       ` Dave Hansen
2010-09-16  1:33         ` KAMEZAWA Hiroyuki
2010-09-24 13:02 ` Pavel Machek

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=20100914234714.8AF506EA@kernel.beaverton.ibm.com \
    --to=dave@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lnxninja@linux.vnet.ibm.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