Dave Hansen <dave@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>