[RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[Dave Hansen]

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>

Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[KAMEZAWA Hiroyuki]

On Tue, 14 Sep 2010 16:47:14 -0700
Dave Hansen <dave@linux.vnet.ibm.com> wrote:

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

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

Thanks,
-Kame

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

Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[KOSAKI Motohiro]

> >  ==============================================================
> >  
> > 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");
> 
> 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!".


	Libenter homines id quod volunt credunt.
		Gaius Julius Caesar "Commentarii de Bello Gallico" 3-18



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

Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[Dave Hansen]

On Wed, 2010-09-15 at 13:53 +0900, KOSAKI Motohiro wrote:
> > >  ==============================================================
> > >  
> > > 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");
> > 
> > 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!".

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.

-- Dave

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

Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[Eric W. Biederman]

Dave Hansen <dave@linux.vnet.ibm.com> writes:

> On Wed, 2010-09-15 at 13:53 +0900, KOSAKI Motohiro wrote:
>> > >  ==============================================================
>> > >  
>> > > 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");
>> > 
>> > 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!".
>
> 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.

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.

Thinking about it drop_caches is sufficiently limited I don't see
drop_caches being even to mask problems so Dave I think your basic
concern is overrated.

As for your documentation update your wording change seems to me to be
more obtuse, and in a scolding tone.  If you want people not to use
this facility you should educate people not scold them.

Perhaps something like:

Calling /proc/sys/vm/drop_caches pessimizes system performance.  The
pages freed by writing to drop_caches are easily repurposed when the
need arises, but the kernel instead of wasting those pages by leaving
them holding nothing, instead uses those pages to increase the size
of the filesystem cache.  The larger filesystem cache increases
the likely hood any filesystem access will get a cache hit and will not
need to read from disk.

Eric

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

Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[Dave Hansen]

On Wed, 2010-09-15 at 11:37 -0700, Eric W. Biederman wrote:
> > 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. 

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

-- Dave

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

Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[Eric W. Biederman]

Dave Hansen <dave@linux.vnet.ibm.com> writes:

> On Wed, 2010-09-15 at 11:37 -0700, Eric W. Biederman wrote:
>> > 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. 
>
> Was it the reclaimable caches doing it, though?  The other really common
> cause is kmalloc() leaks.

It was reclaimable caches.  He kept seeing the cache sizes of the
problem caches shrink.  On an idle system he said he was seeing
about 16MB/min getting free or something like that.  Something
that would take hours and hours before things freed up.

I asked and my friend told me that according to slabtop the slab
with the most memory used kept changing dramatically and he could
not see a pattern.

So at least on one old kernel on one strange workload there was a problem.

Eric

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

Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[Tim Pepper]

On Wed 15 Sep at 13:33:03 +0900 kamezawa.hiroyu@jp.fujitsu.com said:
> >  
> > 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");
> 
> 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?

-- 
Tim Pepper  <lnxninja@linux.vnet.ibm.com>
IBM Linux Technology Center

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

Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[KAMEZAWA Hiroyuki]

On Wed, 15 Sep 2010 12:24:55 -0700
"Tim Pepper" <lnxninja@linux.vnet.ibm.com> wrote:

> On Wed 15 Sep at 13:33:03 +0900 kamezawa.hiroyu@jp.fujitsu.com said:
> > >  
> > > 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");
> > 
> > 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. 

Thanks,
-Kame






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

Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[Dave Hansen]

On Thu, 2010-09-16 at 09:12 +0900, KAMEZAWA Hiroyuki wrote:
> 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.

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?

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

-- Dave

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

Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[KAMEZAWA Hiroyuki]

On Wed, 15 Sep 2010 18:21:47 -0700
Dave Hansen <dave@linux.vnet.ibm.com> wrote:

> On Thu, 2010-09-16 at 09:12 +0900, KAMEZAWA Hiroyuki wrote:
> > 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.
> 
> 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? 

I hear they have a ton of extra memory. Just open() slows down.

> It usually balances out the  dentry/inode caches.
> 
> Would this user be better off with a smaller dentry hash in general? 

Maybe. I hear most of files were created-but-never-used data and logs.

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

I'm not sure. I think they have no boot option of hash size.


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

Showing "Warning" means ", it's possibly bug." for almost all customers.
We'll get tons of "regression" report ;)

If you really want to add messages, please raise log level.
NOTICE or INFO sounds better(and moderate) to me because it's easy to explain
"Don't worry about the message, your kernel is stable and don't need to reboot.
 But please check the peformance, it tends to go bad. You lose cache.".
BTW, what(1or2or3) was writtern to "drop_cache" is important. please show.

Thanks,
-Kame







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

Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

[Pavel Machek]

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>