On Mon, Aug 05, 2013 at 09:20:13AM +0200, Michal Hocko wrote:

On Sun 04-08-13 21:13:44, KOSAKI Motohiro wrote:

quoted

On Sun, Aug 4, 2013 at 4:07 AM, Michal Hocko [off-list ref] wrote:

quoted

On Sat 03-08-13 16:16:58, KOSAKI Motohiro wrote:

quoted

quoted

quoted

quoted

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.
 

quoted

quoted

quoted

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