Message-ID: <CAHGf_=o19rxB=neUPzZAeL9eeLnksKcbqCJjc+vg=EhYtnuwCw@mail.gmail.com>
Date:	Sun, 4 Aug 2013 21:13:44 -0400
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	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 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.

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


>> While the purpose is to shoot misuse, I don't think we can trust
>> userland app.  If "If somebody wants to shoot his feet then we cannot
>> do much about it." is true, this patch is useless. OK, we still catch
>> the right user.
>
> I do not think it is useless. It will print a message for all those
> users initially. It is a matter of user how to deal with it.

If it is userland matter, we don't need additional logging at all. userland
can write their own log. Again, if a crazy guys write blog "Hey! we should
use echo 7 > /proc/sys/vm/drop_caches" always, we will come back the
original problem. You and Dave wrote we need to care wrong, rumor and
crazy drop_caches usage. And if so, you need to think new additional
crazy rumor.


>> But we never want to know who is the right users, right?
>
> Well, those that are curious about a new message in the lock and come
> back to us asking what is going on are those we are primarily interested
> in.

I didn't say the message is useless. I did say hidden drop-cache user
is useless.
--
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