On Tue 07-08-18 08:09:44, Tejun Heo wrote: > On Tue, Aug 07, 2018 at 09:13:32AM +0200, Michal Hocko wrote: > > > * It's the same information as memory.stat but would be in a different > > > format and will likely be a bit of an eyeful. > > > > > > * It can easily become a really long line. Each kernel log can be ~1k > > > in length and there can be other limits in the log pipeline > > > (e.g. netcons). > > > > Are we getting close to those limits? > > Yeah, I think the stats we have can already go close to or over 500 > bytes easily, which is already pushing the netcons udp packet size > limit. > > > > * The information is already multi-line and cgroup oom kills don't > > > take down the system, so there's no need to worry about scroll back > > > that much. Also, not printing recursive info means the output is > > > well-bound. > > > > Well, on the other hand you can have a lot of memcgs under OOM and then > > swamp the log a lot. > > idk, the info dump is already multi-line. If we have a lot of memcgs > under OOM, we're already kinda messed up (e.g. we can't tell which > line is for which oom). Well, I am not really worried about interleaved oom reports because they do use oom_lock so this shouldn't be a problem. I just meant to say that a lot of memcg ooms will swamp the log and having more lines doesn't really help. That being said. I will not really push hard. If there is a general consensus with this output I will not stand in the way. But I believe that more compact oom report is both nicer and easier to read. At least from my POV and I have processed countless number of those. -- Michal Hocko SUSE Labs
