On 2018/10/15 20:24, Michal Hocko wrote: > On Mon 15-10-18 19:57:35, Tetsuo Handa wrote: >> On 2018/10/15 17:19, Michal Hocko wrote: >>> As so many dozens of times before, I will point you to an incremental >>> nature of changes we really prefer in the mm land. We are also after a >>> simplicity which your proposal lacks in many aspects. You seem to ignore >>> that general approach and I have hard time to consider your NAK as a >>> relevant feedback. Going to an extreme and basing a complex solution on >>> it is not going to fly. No killable process should be a rare event which >>> requires a seriously misconfigured memcg to happen so wildly. If you can >>> trigger it with a normal user privileges then it would be a clear bug to >>> address rather than work around with printk throttling. >>> >> >> I can trigger 200+ times / 900+ lines / 69KB+ of needless OOM messages >> with a normal user privileges. This is a lot of needless noise/delay. > > I am pretty sure you have understood the part of my message you have > chosen to not quote where I have said that the specific rate limitting > decisions can be changed based on reasonable configurations. There is > absolutely zero reason to NAK a natural decision to unify the throttling > and cook a per-memcg way for a very specific path instead. > >> No killable process is not a rare event, even without root privileges. >> >> [root@ccsecurity kumaneko]# time ./a.out >> Killed >> >> real 0m2.396s >> user 0m0.000s >> sys 0m2.970s >> [root@ccsecurity ~]# dmesg | grep 'no killable' | wc -l >> 202 >> [root@ccsecurity ~]# dmesg | wc >> 942 7335 70716 > > OK, so this is 70kB worth of data pushed throug the console. Is this > really killing any machine? > Nobody can prove that it never kills some machine. This is just one example result of one example stress tried in my environment. Since I am secure programming man from security subsystem, I really hate your "Can you trigger it?" resistance. Since this is OOM path where nobody tests, starting from being prepared for the worst case keeps things simple.