Hi azurIt, On Fri, Jun 28, 2013 at 12:06:13PM +0200, azurIt wrote: > >It's not a kernel thread that does it because all kernel-context > >handle_mm_fault() are annotated properly, which means the task must be > >userspace and, since tasks is empty, have exited before synchronizing. > > > >Can you try with the following patch on top? > > > Michal and Johannes, > > i have some observations which i made: Original patch from Johannes > was really fixing something but definitely not everything and was > introducing new problems. I'm running unpatched kernel from time i > send my last message and problems with freezing cgroups are occuring > very often (several times per day) - they were, on the other hand, > quite rare with patch from Johannes. That's good! > Johannes, i didn't try your last patch yet. I would like to wait > until you or Michal look at my last message which contained detailed > information about freezing of cgroups on kernel running your > original patch (which was suppose to fix it for good). Even more, i > would like to hear your opinion about that stucked processes which > was holding web server port and which forced me to reboot production > server at the middle of the day :( more information was in my last > message. Thank you very much for your time. I looked at your debug messages but could not find anything that would hint at a deadlock. All tasks are stuck in the refrigerator, so I assume you use the freezer cgroup and enabled it somehow? Sorry about your production server locking up, but from the stacks I don't see any connection to the OOM problems you were having... :/ -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>