On 06/29/2015 11:32 AM, Michal Hocko wrote: > On Thu 25-06-15 18:27:10, Nikolay Borisov wrote: >> >> >> On 06/25/2015 06:18 PM, Michal Hocko wrote: >>> On Thu 25-06-15 17:34:22, Nikolay Borisov wrote: >>>> On 06/25/2015 05:05 PM, Michal Hocko wrote: >>>>> On Thu 25-06-15 16:49:43, Nikolay Borisov wrote: >>>>> [...] >>>>>> How would you advise to rectify such situation? >>>>> >>>>> As I've said. Check the oom victim traces and see if it is holding any >>>>> of those locks. >>>> >>>> As mentioned previously all OOM traces are identical to the one I've >>>> sent - OOM being called form the page fault path. >>> >>> By identical you mean that all of them kill the same task? Or just that >>> the path is same (which wouldn't be surprising as this is the only path >>> which triggers memcg oom killer)? >> >> The code path is the same, the tasks being killed are different > > Is the OOM killer triggered only for a singe memcg or others misbehave > as well? Generally OOM would be triggered for whichever memcg runs out of resources but so far I've only observed that the D state issue happens in a single containers. However, this in turn might affect other processes if they try to sleep on the same jbd2 journal . -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
