Date:	Tue, 17 Sep 2013 11:14:08 -0400
From:	Johannes Weiner <hannes@...xchg.org>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>, dave.hansen@...el.com,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>, bp@...e.de,
	Dave Hansen <dave@...ux.vnet.ibm.com>
Subject: Re: [PATCH resend] drop_caches: add some documentation and info
 message

On Mon, Aug 05, 2013 at 09:20:13AM +0200, Michal Hocko wrote:
> On Sun 04-08-13 21:13:44, KOSAKI Motohiro wrote:
> > On Sun, Aug 4, 2013 at 4:07 AM, Michal Hocko <mhocko@...e.cz> wrote:
> > > On Sat 03-08-13 16:16:58, KOSAKI Motohiro wrote:
> > >> >>> You missed the "!".  I'm proposing that setting the new bit 2 will
> > >> >>> permit people to prevent the new printk if it is causing them problems.
> > >> >>
> > >> >> No I don't. I'm sure almost all abuse users think our usage is correct. Then,
> > >> >> I can imagine all crazy applications start to use this flag eventually.
> > >> >
> > >> > I guess we do not care about those. If somebody wants to shoot his feet
> > >> > then we cannot do much about it. The primary motivation was to find out
> > >> > those that think this is right and they are willing to change the setup
> > >> > once they know this is not the right way to do things.
> > >> >
> > >> > I think that giving a way to suppress the warning is a good step. Log
> > >> > level might be to coarse and sysctl would be an overkill.
> > >>
> > >> When Dave Hansen reported this issue originally, he explained a lot of userland
> > >> developer misuse /proc/drop_caches because they don't understand what
> > >> drop_caches do.
> > >> So, if they never understand the fact, why can we trust them? I have no
> > >> idea.
> > >
> > > Well, most of that usage I have come across was legacy scripts which
> > > happened to work at a certain point in time because we sucked.
> > > Thinks have changed but such scripts happen to survive a long time.
> > > We are primarily interested in those.
> > 
> > Well, if the main target is shell script, task_comm and pid don't help us
> > a lot. I suggest to add ppid too.
> 
> I do not have any objections to add ppid.
>  
> > >> Or, if you have different motivation w/ Dave, please let me know it.
> > >
> > > We have seen reports where users complained about performance drop down
> > > when in fact the real culprit turned out to be such a clever script
> > > which dropped caches on the background thinking it will help to free
> > > some memory. Such cases are tedious to reveal.
> > 
> > Imagine such script have bit-2 and no logging output. Because
> > the script author think "we are doing the right thing".
> > Why distro guys want such suppress messages?
> 
> I am not really pushing this suppressing functionality. I just
> understand that there might be some legitimate use for supressing and if
> that is a must for merging the printk, I can live with that.

Is there any conceivable use case that legitimately drops caches at
such a rate that the logging output becomes a problem?

We export an interface that provides something useful in exceptional
cases but has significant impact on the kernel's ongoing operations.
Kernel developers want this information in problem reports.  It's the
same thing as forcefully tainting kernels when a proprietary module is
loaded.
--
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/

Powered by blists - more mailing lists