From: Pavel Machek <pavel@ucw.cz>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
lnxninja@linux.vnet.ibm.comc, Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation
Date: Fri, 24 Sep 2010 15:02:17 +0200 [thread overview]
Message-ID: <20100924130216.GA1810@ucw.cz> (raw)
In-Reply-To: <20100914234714.8AF506EA@kernel.beaverton.ibm.com>
Hi!
> 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!
Its worse. IIRC android actually uses it in production. And, IIRC akpm
told me that drop_caches does not include enough locking to be
safe. If that's still the case, it should be documented.
> -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.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
lnxninja@linux.vnet.ibm.comc, Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation
Date: Fri, 24 Sep 2010 15:02:17 +0200 [thread overview]
Message-ID: <20100924130216.GA1810@ucw.cz> (raw)
In-Reply-To: <20100914234714.8AF506EA@kernel.beaverton.ibm.com>
Hi!
> 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!
Its worse. IIRC android actually uses it in production. And, IIRC akpm
told me that drop_caches does not include enough locking to be
safe. If that's still the case, it should be documented.
> -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.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 prev parent reply other threads:[~2010-09-24 13:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-14 23:47 [RFC][PATCH] update /proc/sys/vm/drop_caches documentation Dave Hansen
2010-09-14 23:47 ` Dave Hansen
2010-09-15 4:33 ` KAMEZAWA Hiroyuki
2010-09-15 4:33 ` KAMEZAWA Hiroyuki
2010-09-15 4:53 ` KOSAKI Motohiro
2010-09-15 4:53 ` KOSAKI Motohiro
2010-09-15 6:14 ` Dave Hansen
2010-09-15 6:14 ` Dave Hansen
2010-09-15 18:37 ` Eric W. Biederman
2010-09-15 18:37 ` Eric W. Biederman
2010-09-15 19:27 ` Dave Hansen
2010-09-15 19:27 ` Dave Hansen
2010-09-15 21:34 ` Eric W. Biederman
2010-09-15 21:34 ` Eric W. Biederman
2010-09-15 19:24 ` Tim Pepper
2010-09-15 19:24 ` Tim Pepper
2010-09-16 0:12 ` KAMEZAWA Hiroyuki
2010-09-16 0:12 ` KAMEZAWA Hiroyuki
2010-09-16 1:21 ` Dave Hansen
2010-09-16 1:21 ` Dave Hansen
2010-09-16 1:33 ` KAMEZAWA Hiroyuki
2010-09-16 1:33 ` KAMEZAWA Hiroyuki
2010-09-24 13:02 ` Pavel Machek [this message]
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=20100924130216.GA1810@ucw.cz \
--to=pavel@ucw.cz \
--cc=akpm@osdl.org \
--cc=dave@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lnxninja@linux.vnet.ibm.comc \
/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.