linux-kernel - Re: [RFC][PATCH] update /proc/sys/vm/drop

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Sep 2010 11:37:18 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Dave Hansen <dave@...ux.vnet.ibm.com>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	lnxninja@...ux.vnet.ibm.com
Subject: Re: [RFC][PATCH] update /proc/sys/vm/drop_caches documentation

Dave Hansen <dave@...ux.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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/