On Fri, Oct 8, 2010 at 11:53 PM, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote: > * Dave Young <hidave.darkstar@xxxxxxxxx> [2010-10-08 21:33:02]: > >> On Fri, Oct 8, 2010 at 9:09 PM, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote: >> > * Dave Young <hidave.darkstar@xxxxxxxxx> [2010-10-05 20:45:21]: >> > >> >> Balloon could cause guest memory oom killing and panic. >> >> >> >> Add oom notify to leak some memory and retry fill balloon after 5 minutes. >> >> >> >> At the same time add a mutex to protect balloon operations >> >> because we need leak balloon in oom notifier and give back freed value. >> >> >> >> Thanks Anthony Liguori for his sugestion about inflate retrying. >> >> Sometimes it will cause endless inflate/oom/delay loop, >> >> so I think next step is to add an option to do noretry-when-oom balloon. >> >> >> >> Signed-off-by: Dave Young <hidave.darkstar@xxxxxxxxx> >> > >> > Won't __GFP_NORETRY prevent OOM? Could you please describe how you >> > tested the patch? >> >> I have not tried __GFP_NORETRY, it should work, but balloon thread >> will keep wasting cpu resource to allocating. >> >> >> To test the patch, just balloon to small than minimal memory. >> >> I use "balloon 30" in qemu monitor to limit slackware guest memory >> usage. The normal memory used is ~40M. >> >> Actually we need to differentiate the process which caused oom. If it >> is balloon thread we should just stop ballooning, if it is others we >> can do something like this patch, e.g. retry ballooning after 5 >> minutes. > > Ideally the balloon thread should never OOM with __GFP_NORETRY (IIRC). > The other situation should be dealt with, we should free up any pages > we have. I wonder if the timeout should be a sysctl tunable. balbir, you are right, the oom is not from balloon alloc_page. balloon thread cause memory low, then afterwards vm readahead code cause oom. With oom notifier patch oom killing does not happen in my test > > -- > Â Â Â ÂThree Cheers, > Â Â Â ÂBalbir > -- Regards dave -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
