update /proc/sys/vm/drop_caches documentation

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 <[email protected]>

---

 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

Documentation/sysctl/vm.txt renamed from Documentation/sysctl/vm.txt~update-drop_caches-documentation +12 -2

@@ -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

fs/drop_caches.c int drop_caches_sysctl_handler(ctl_table · line 51

Quoted 11 lines

==============================================================

diff -puN fs/drop_caches.c~update-drop_caches-documentation fs/drop_caches.c

fs/drop_caches.c renamed from fs/drop_caches.c~update-drop_caches-documentation +2 -0

@@ -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");

Documentation updeta seems good but showing warning seems to be meddling to me.

Quoted 13 lines

fs/drop_caches.c int drop_caches_sysctl_handler(ctl_table · line 51

Quoted 11 lines

==============================================================

diff -puN fs/drop_caches.c~update-drop_caches-documentation fs/drop_caches.c

fs/drop_caches.c renamed from fs/drop_caches.c~update-drop_caches-documentation +2 -0

@@ -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");

Documentation updeta seems good but showing warning seems to be meddling to me.

Agreed.

If the motivation is blog's bogus rumor, this is no effective. I easily imazine they will write "Hey, drop_caches may output strange message, but please ignore it!".

Quoted 14 lines · KOSAKI Motohiro

Quoted 13 lines

fs/drop_caches.c int drop_caches_sysctl_handler(ctl_table · line 51

Quoted 11 lines

==============================================================

diff -puN fs/drop_caches.c~update-drop_caches-documentation fs/drop_caches.c

fs/drop_caches.c renamed from fs/drop_caches.c~update-drop_caches-documentation +2 -0

@@ -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");

Documentation updeta seems good but showing warning seems to be meddling to me.

Quoted 5 lines

Agreed.

If the motivation is blog's bogus rumor, this is no effective. I easily imazine they will write "Hey, drop_caches may output strange message, but please ignore it!".

Fair enough. But, is there a point that we _should_ be warning? If someone is doing this every minute, or every hour, something is pretty broken. Should we at least be doing a WARN_ON() so that the TAINT_WARN is set?

I'm worried that there are users out there experiencing real problems that aren't reporting it because "workarounds" like this just paper over the issue.

Quoted 3 lines

I'm worried that there are users out there experiencing real problems that aren't reporting it because "workarounds" like this just paper over the issue.

For what it is worth. I had a friend ask me about a system that had 50% of it's memory consumed by slab caches. 20GB out of 40GB. The kernel was suse? 2.6.27 so it's old, but if you are curious. /proc/sys/vm/drop_caches does nothing in that case.

Quoted 4 lines · Eric W. Biederman

Quoted 3 lines

I'm worried that there are users out there experiencing real problems that aren't reporting it because "workarounds" like this just paper over the issue.

Quoted 4 lines

For what it is worth. I had a friend ask me about a system that had 50% of it's memory consumed by slab caches. 20GB out of 40GB. The kernel was suse? 2.6.27 so it's old, but if you are curious. /proc/sys/vm/drop_caches does nothing in that case.

Was it the reclaimable caches doing it, though? The other really common cause is kmalloc() leaks.

fs/drop_caches.c int drop_caches_sysctl_handler(ctl_table · line 51

Quoted 10 lines

diff -puN fs/drop_caches.c~update-drop_caches-documentation fs/drop_caches.c

fs/drop_caches.c renamed from fs/drop_caches.c~update-drop_caches-documentation +2 -0

@@ -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");

Documentation updeta seems good but showing warning seems to be meddling to me.

Quoted 12 lines · On Wed 15 Sep at 13:33:03 +0900 [email protected] said:

fs/drop_caches.c int drop_caches_sysctl_handler(ctl_table · line 51

Quoted 10 lines

diff -puN fs/drop_caches.c~update-drop_caches-documentation fs/drop_caches.c

fs/drop_caches.c renamed from fs/drop_caches.c~update-drop_caches-documentation +2 -0

@@ -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");

Documentation updeta seems good but showing warning seems to be meddling to me.

We already have examples of things where we warn in order to turn up "interesting" userspace code, in the hope of starting dialog and getting things fixed for the future. I don't see this so much as meddling as one of the fundamental aspects of open source.

drop_caches probably originally should have gone in under a CONFIG_DEBUG (even if all the distros would have turned it on), and had a WARN_ON (personally I'd argue for this compared to WARN_ONCE()), and even have been exposed in debugfs not procfs...but it's part of the "the interface" at this point.

Somebody doing debug and testing which leverages drop_caches should not be bothered by a WARN_ON(). Somebody using it to "fix" the kernel with repeated/regular calls to drop_caches should get called out for fixing themselves and the WARN_*()'s noting the comm could help that, unless somebody has a use case where repeated/regular calls to drop_caches is valid and not connected to buggy usage or explicit performance debug/testing?

I hear a customer's case. His server generates 3-80000+ new dentries per day and dentries will be piled up to 1000000+ in a month. This makes open()'s performance very bad because Hash-lookup will be heavy. (He has very big memory.)

What we could ask him was
- rewrite your application. or
- reboot once in a month (and change hash size) or
- drop_cache once in a month

Because their servers cannot stop, he used drop_caches once in a month while his server is idle, at night. Changing HashSize cannot be a permanent fix because he may not stop the server for years.

For rare users who have 10000000+ of files and tons of free memory, drop_cache can be an emergency help.

Quoted 9 lines · KAMEZAWA Hiroyuki

I hear a customer's case. His server generates 3-80000+ new dentries per day and dentries will be piled up to 1000000+ in a month. This makes open()'s performance very bad because Hash-lookup will be heavy. (He has very big memory.)

What we could ask him was
- rewrite your application. or
- reboot once in a month (and change hash size) or
- drop_cache once in a month

Quoted 3 lines

Because their servers cannot stop, he used drop_caches once in a month while his server is idle, at night. Changing HashSize cannot be a permanent fix because he may not stop the server for years.

That is a really interesting case.

They must have a *ton* of completely extra memory laying around. Do they not have much page cache activity?

It usually balances out the dentry/inode caches.

Would this user be better off with a smaller dentry hash in general?

Is it special hardware that should _have_ a lower default hash size?

Quoted 2 lines

For rare users who have 10000000+ of files and tons of free memory, drop_cache can be an emergency help.

In this case, though, would a WARN_ON() in an emergency be such a bad thing? They evidently know what they're doing, and shouldn't be put off by it.

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!

Documentation/sysctl/vm.txt renamed from Documentation/sysctl/vm.txt~update-drop_caches-documentation +12 -2

-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.