On Tue 28-11-17 19:05:54, Yafang Shao wrote: > 2017-11-28 18:48 GMT+08:00 Michal Hocko <mhocko@xxxxxxxx>: > > On Tue 28-11-17 11:37:23, Jan Kara wrote: > >> On Mon 27-11-17 10:19:39, Michal Hocko wrote: > >> > Andrew, > >> > could you simply send this to Linus. If we _really_ need something to > >> > prevent misconfiguration, which I doubt to be honest, then it should be > >> > thought through much better. > >> > >> What's so bad about the warning? I think warning about such > >> misconfiguration is not a bad thing per se. Maybe it should be ratelimited > >> and certainly the condition is too loose as your example shows but in > >> principle I'm not against it and e.g. making the inequality in the condition > >> strict like: > >> > >> if (unlikely(bg_thresh > thresh)) > >> > >> or at least > >> > >> if (unlikely(bg_thresh >= thresh && thresh > 0)) > >> > >> would warn about cases where domain_dirty_limits() had to fixup bg_thresh > >> manually to make writeback throttling work and avoid reclaim stalls which > >> is IMHO a sane thing... > > > > If it generates false positives then it is more harmful than useful. And > > even if it doesn't, what is the point? Do we check that other related > > knobs are configured properly? I do not think so, we simply rely on > > admins doing sane things. > > Not all admins are good at tuning this. > I don't think every SE knows how to tune vm.dirty_background_bytes and > vm.dirty_background_bytes. Only kernel experts could do that. So are you saying that people tend to configure system randomly without reading documentation? Seriously, this whole thing has generated much more discussion than it deserves. I really fail to see why you are insisting without admiting that the thing is just broken and you do not have a great idea to fix it without adding even more hacks on top of what we have currently. > At least this warning could help them to learn what happend instead of > knowing nothing. That is what we have a documentation for. If it needs improvements then I am all for it. -- 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>
