>[...] >> My script detected another freezed cgroup today, sending stacks. Is >> there anything interesting? > >3 tasks are sleeping and waiting for somebody to take an action to >resolve memcg OOM. The memcg oom killer is enabled for that group? If >yes, which task has been selected to be killed? You can find that in oom >report in dmesg. > >I can see a way how this might happen. If the killed task happened to >allocate a memory while it is exiting then it would get to the oom >condition again without freeing any memory so nobody waiting on the >memcg_oom_waitq gets woken. We have a report like that: >https://lkml.org/lkml/2013/7/31/94 > >The issue got silent in the meantime so it is time to wake it up. >It would be definitely good to see what happened in your case though. >If any of the bellow tasks was the oom victim then it is very probable >this is the same issue. Here it is: http://watchdog.sk/lkml/kern5.log Processes were killed by my script at about 11:05:35. azur -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
