Hi, I have recently run in the following issue: under certain conditions, if emulator process have exceeded its own memory limit in the cgroup and oom shot it, /proc entry may stay long indefinitely. There are two possible side-effects - at first, if one will try to read cmdline from such entry, his request will hang indefinitely long too, e.g. if issuing ``ps aux'' once per minute will fill out default PID limit in less a half of day by ps processes in D state. Second effect may appear only on heavily loaded node - scheduler process will eat 100% of selected cores (almost always at only one), with system becoming unresponsive in a couple of minutes. This should be reproduced easily:
- start kvm process - put in to memory cgroup and set the limits - disable oom_killer via oom_control - simply put the process into oom condition (using balloon, it should be very simple) - check kvm process state - if it stuck in D state, all should be okay, since you`re able to catch oom condition - simply send TERM signal and raise memory limit by nonsignificant amount and process wiil end normally. If you`re observing kvm process with triggered under_oom flag and in _sleep_ state, TERM signal will kill it, with nice lock described above. I have solved problem by quite stupid workaround - after getting informed of oom event(w/ disabled oom in cg), I`m freezing kvm process via freezer cg, therefore moving it to D state, then sending it TERM, then raising memory limits and finally unfreezing it - it is very ugly, but at least I have get rid of the problem. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
