* 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. -- Three Cheers, Balbir -- 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
