Hi esteemed kernel devs! Please be sure to CC answers to me personally so they're flagged for my attention. I've filed https://bugzilla.kernel.org/show_bug.cgi?id=124641 in Bugzilla, so I'll try not to repeat too many key details here; GKH has asked that I bring the conversation to email, LKML, and the cgroups list. Long story short, we see the behavior described in this LKML thread http://lkml.iu.edu/hypermail/linux/kernel/1606.2/00736.html and (we think) addressed by the patch therein - memory cgroups don't seem to be automatically garbage collected during runtime and must be manually released to allow space for new cgroups after the 65336 limit is reached. At this time, the only way we've found to release them is to send echo 1 > /proc/sys/vm/drop_caches to the kernel. The title of this message is the dmesg line we typically see in machines that have breached the limit, and are trying in vain to remove a cgroup beyond the 65536 ceiling. We've asked CoreOS to cut a build with the patch from LKML and we'll test it shortly to see if it alleviates the problem. We'll update this list with results of testing against that patch and also test against a 4.6.x kernel as soon as possible. Let us know if you need the full stack trace or other diagnostic info. Cheers! -- John Garcia Technical Support Engineer Mesosphere.io -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
