linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Dave Hansen <dave@linux.vnet.ibm.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	lnxninja@linux.vnet.ibm.com
Subject: Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation
Date: Wed, 15 Sep 2010 11:37:18 -0700	[thread overview]
Message-ID: <m1d3se7t0h.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <1284531262.27089.15725.camel@nimitz> (Dave Hansen's message of "Tue, 14 Sep 2010 23:14:22 -0700")

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>

  reply	other threads:[~2010-09-15 18:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-14 23:47 Dave Hansen
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 [this message]
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=m1d3se7t0h.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=dave@linux.vnet.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.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