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. > 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. > 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. > 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. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>