On Mon 25-11-19 17:12:54, Yafang Shao wrote: > On Mon, Nov 25, 2019 at 4:20 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > On Sat 23-11-19 13:52:57, Yafang Shao wrote: > > > On Fri, Nov 22, 2019 at 6:28 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > > > > > On Wed 20-11-19 20:23:54, Yafang Shao wrote: > > > > > On Wed, Nov 20, 2019 at 7:40 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > > > > > > > > > On Wed 20-11-19 18:53:44, Yafang Shao wrote: > > > > > > > On Wed, Nov 20, 2019 at 6:22 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > On Wed 20-11-19 03:53:05, Yafang Shao wrote: > > > > > > > > > A task running in a memcg may OOM because of the memory.min settings of his > > > > > > > > > slibing and parent. If this happens, the current oom messages can't show > > > > > > > > > why file page cache can't be reclaimed. > > > > > > > > > > > > > > > > min limit is not the only way to protect memory from being reclaim. The > > > > > > > > memory might be pinned or unreclaimable for other reasons (e.g. swap > > > > > > > > quota exceeded for memcg). > > > > > > > > > > > > > > Both swap or unreclaimabed (unevicteable) is printed in OOM messages. > > > > > > > > > > > > Not really. Consider a memcg which has reached it's swap limit. The > > > > > > anonymous memory is not really reclaimable even when there is a lot of > > > > > > swap space available. > > > > > > > > > > > > > > > > The memcg swap limit is already printed in oom messages, see bellow, > > > > > > > > > > [ 141.721625] memory: usage 1228800kB, limit 1228800kB, failcnt 18337 > > > > > [ 141.721958] swap: usage 0kB, limit 9007199254740988kB, failcnt 0 > > > > > > > > But you do not have any insight on the swap limit down the oom > > > > hierarchy, do you? > > > > > > > > > > > Why not just print the memcgs which are under memory.min protection or > > > > > > > something like a total number of min protected memory ? > > > > > > > > > > > > Yes, this would likely help. But the main question really reamains, is > > > > > > this really worth it? > > > > > > > > > > > > > > > > If it doesn't cost too much, I think it is worth to do it. > > > > > As the oom path is not the critical path, so adding some print info > > > > > should not add much overhead. > > > > > > > > Generating a lot of output for the oom reports has been a real problem > > > > in many deployments. > > > > > > So why not only print non-zero counters ? > > > If some counters are 0, we don't print them, that can reduce the oom reports. > > > > > > Something like "isolated_file:0 unevictable:0 dirty:0 writeback:0 > > > unstable:0" can all be removed, > > > and we consider them as zero by default. > > > > because that would make parsing more complex. > > > > > I mean we can optimze the OOM reports and only print the useful > > > information to make it not be a problem in many deployments. > > > > We can, but it would be great to have it backed by som real usecase to > > change the current behavior. I haven't heard anything so far. It is all > > about "this would be nice" without a strong justification. > > Because I was told by you that "Generating a lot of output for the oom > reports has been a real problem in many deployments.". > Maybe I misunderstood you : ( I meant to say that we do not want to add more output unless there is a real need. Changing the existing output is usually tricky because there are existing parsers that might break on that change. Not that we do guarantee the output format officially but we try hard to preserve as much as we can if that is possible. That being said maybe the lack of reclaim guarantee information is a more wide spread problem and more people are suffering from it. If that is the case then the justification would be much easier to formulate. -- Michal Hocko SUSE Labs
