Hello everyone, On Wed, Jan 07, 2015 at 03:28:04PM +0100, Michal Hocko wrote: > Instead we shouldn't pretend that GFP_KERNEL is basically GFP_NOFAIL. > The question is how to get there without too many regressions IMHO. > Or maybe we should simply bite a bullet and don't be cowards and simply > deal with bugs as they come. If something really cannot deal with the > failure it should tell that by a proper flag. Not related to memcg but related to GFP_NOFAIL behavior, a couple of months ago while stress testing some code I've been working on, I run into several OOM livelocks which may be the same you're reporting here and I reliably fixed those (at least for my load) so I could keep going with my work. I didn't try to submit these changes yet, but this discussion rings a bell... so I'm sharing my changes below in this thread in case it may help: http://git.kernel.org/cgit/linux/kernel/git/andrea/aa.git/commit/?id=00e91f97df9861454f7e0701944d7de2c382ffb9 http://git.kernel.org/cgit/linux/kernel/git/andrea/aa.git/commit/?id=a0fcf2323b2e4cffd750c1abc1d2c138acdefcc8 http://git.kernel.org/cgit/linux/kernel/git/andrea/aa.git/commit/?id=798b7f9d549664f8c0007c6416a2568eedd75d6a Thanks, Andrea -- 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>