| Message ID | 20110426052916.GA11933@darkstar (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> When memory pressure is high, virtio ballooning will probably cause oom killing. > Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it > will make memory becoming low then memory alloc of other processes will trigger > oom killing. It is not desired behaviour. > > Here disable oom killer in fill_balloon to address this issue. > > Signed-off-by: Dave Young <hidave.darkstar@gmail.com> > --- > drivers/virtio/virtio_balloon.c | 3 +++ > 1 file changed, 3 insertions(+) > > --- linux-2.6.orig/drivers/virtio/virtio_balloon.c 2010-10-13 10:14:38.000000000 +0800 > +++ linux-2.6/drivers/virtio/virtio_balloon.c 2011-04-26 11:38:43.979785141 +0800 > @@ -25,6 +25,7 @@ > #include <linux/freezer.h> > #include <linux/delay.h> > #include <linux/slab.h> > +#include <linux/oom.h> > > struct virtio_balloon > { > @@ -102,6 +103,7 @@ static void fill_balloon(struct virtio_b > /* We can only do one array worth at a time. */ > num = min(num, ARRAY_SIZE(vb->pfns)); > > + oom_killer_disable(); I think this patch need proper comment at least. My first impression is, "Hm, __GFP_NORETRY should prevent oom, why is this necessary?". So, this actually prevent _another_ thread call out_of_memory(). Also, Here doesn't have any exclusion against hibernation (ie another oom_killer_disable() callsite). It should be described why lock is unnecessary. Thanks. > for (vb->num_pfns = 0; vb->num_pfns < num; vb->num_pfns++) { > struct page *page = alloc_page(GFP_HIGHUSER | __GFP_NORETRY | > __GFP_NOMEMALLOC | __GFP_NOWARN); > @@ -119,6 +121,7 @@ static void fill_balloon(struct virtio_b > vb->num_pages++; > list_add(&page->lru, &vb->pages); > } > + oom_killer_enable(); > > /* Didn't get any? Oh well. */ > if (vb->num_pfns == 0) > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 26, 2011 at 2:38 PM, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote: >> When memory pressure is high, virtio ballooning will probably cause oom killing. >> Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it >> will make memory becoming low then memory alloc of other processes will trigger >> oom killing. It is not desired behaviour. >> >> Here disable oom killer in fill_balloon to address this issue. >> >> Signed-off-by: Dave Young <hidave.darkstar@gmail.com> >> --- >> drivers/virtio/virtio_balloon.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> --- linux-2.6.orig/drivers/virtio/virtio_balloon.c 2010-10-13 10:14:38.000000000 +0800 >> +++ linux-2.6/drivers/virtio/virtio_balloon.c 2011-04-26 11:38:43.979785141 +0800 >> @@ -25,6 +25,7 @@ >> #include <linux/freezer.h> >> #include <linux/delay.h> >> #include <linux/slab.h> >> +#include <linux/oom.h> >> >> struct virtio_balloon >> { >> @@ -102,6 +103,7 @@ static void fill_balloon(struct virtio_b >> /* We can only do one array worth at a time. */ >> num = min(num, ARRAY_SIZE(vb->pfns)); >> >> + oom_killer_disable(); > > I think this patch need proper comment at least. My first impression > is, "Hm, __GFP_NORETRY should prevent oom, why is this necessary?". > So, this actually prevent _another_ thread call out_of_memory(). Thanks, will fix. > Also, Here doesn't have any exclusion against hibernation (ie another > oom_killer_disable() callsite). It should be described why lock is > unnecessary. Good catch, but lock should better be handled in oom_killer_disable function itself, What do you think? For oom killer multi user there's more problem, if process A disable oom killer then Process B enable oom killer, it is not A want to see, Any thoughts? > > Thanks. > > >> for (vb->num_pfns = 0; vb->num_pfns < num; vb->num_pfns++) { >> struct page *page = alloc_page(GFP_HIGHUSER | __GFP_NORETRY | >> __GFP_NOMEMALLOC | __GFP_NOWARN); >> @@ -119,6 +121,7 @@ static void fill_balloon(struct virtio_b >> vb->num_pages++; >> list_add(&page->lru, &vb->pages); >> } >> + oom_killer_enable(); >> >> /* Didn't get any? Oh well. */ >> if (vb->num_pfns == 0) >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ > > > >
> On Tue, Apr 26, 2011 at 2:38 PM, KOSAKI Motohiro > <kosaki.motohiro@jp.fujitsu.com> wrote: > >> When memory pressure is high, virtio ballooning will probably cause oom killing. > >> Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it > >> will make memory becoming low then memory alloc of other processes will trigger > >> oom killing. It is not desired behaviour. > >> > >> Here disable oom killer in fill_balloon to address this issue. > >> > >> Signed-off-by: Dave Young <hidave.darkstar@gmail.com> > >> --- > >> drivers/virtio/virtio_balloon.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> --- linux-2.6.orig/drivers/virtio/virtio_balloon.c 2010-10-13 10:14:38.000000000 +0800 > >> +++ linux-2.6/drivers/virtio/virtio_balloon.c 2011-04-26 11:38:43.979785141 +0800 > >> @@ -25,6 +25,7 @@ > >> #include <linux/freezer.h> > >> #include <linux/delay.h> > >> #include <linux/slab.h> > >> +#include <linux/oom.h> > >> > >> struct virtio_balloon > >> { > >> @@ -102,6 +103,7 @@ static void fill_balloon(struct virtio_b > >> /* We can only do one array worth at a time. */ > >> num = min(num, ARRAY_SIZE(vb->pfns)); > >> > >> + oom_killer_disable(); > > > > I think this patch need proper comment at least. My first impression > > is, "Hm, __GFP_NORETRY should prevent oom, why is this necessary?". > > So, this actually prevent _another_ thread call out_of_memory(). > > Thanks, will fix. > > > Also, Here doesn't have any exclusion against hibernation (ie another > > oom_killer_disable() callsite). It should be described why lock is > > unnecessary. > > Good catch, but lock should better be handled in oom_killer_disable > function itself, > What do you think? > > For oom killer multi user there's more problem, if process A disable > oom killer then Process B enable oom killer, it is not A want to see, > Any thoughts? If baloon and hibernation don't have any implicit exclusion, you are right. Sorry, I don't virtio internal. please don't ask me. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 26, 2011 at 3:22 PM, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote: >> On Tue, Apr 26, 2011 at 2:38 PM, KOSAKI Motohiro >> <kosaki.motohiro@jp.fujitsu.com> wrote: >> >> When memory pressure is high, virtio ballooning will probably cause oom killing. >> >> Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it >> >> will make memory becoming low then memory alloc of other processes will trigger >> >> oom killing. It is not desired behaviour. >> >> >> >> Here disable oom killer in fill_balloon to address this issue. >> >> >> >> Signed-off-by: Dave Young <hidave.darkstar@gmail.com> >> >> --- >> >> drivers/virtio/virtio_balloon.c | 3 +++ >> >> 1 file changed, 3 insertions(+) >> >> >> >> --- linux-2.6.orig/drivers/virtio/virtio_balloon.c 2010-10-13 10:14:38.000000000 +0800 >> >> +++ linux-2.6/drivers/virtio/virtio_balloon.c 2011-04-26 11:38:43.979785141 +0800 >> >> @@ -25,6 +25,7 @@ >> >> #include <linux/freezer.h> >> >> #include <linux/delay.h> >> >> #include <linux/slab.h> >> >> +#include <linux/oom.h> >> >> >> >> struct virtio_balloon >> >> { >> >> @@ -102,6 +103,7 @@ static void fill_balloon(struct virtio_b >> >> /* We can only do one array worth at a time. */ >> >> num = min(num, ARRAY_SIZE(vb->pfns)); >> >> >> >> + oom_killer_disable(); >> > >> > I think this patch need proper comment at least. My first impression >> > is, "Hm, __GFP_NORETRY should prevent oom, why is this necessary?". >> > So, this actually prevent _another_ thread call out_of_memory(). >> >> Thanks, will fix. >> >> > Also, Here doesn't have any exclusion against hibernation (ie another >> > oom_killer_disable() callsite). It should be described why lock is >> > unnecessary. >> >> Good catch, but lock should better be handled in oom_killer_disable >> function itself, >> What do you think? >> >> For oom killer multi user there's more problem, if process A disable >> oom killer then Process B enable oom killer, it is not A want to see, >> Any thoughts? > > If baloon and hibernation don't have any implicit exclusion, you are > right. For this case, hibernation will freeze balloon thread before call oom_killer_disable, so there's no problem. If we consider future users of oom_killer_disabled, we will have to deal with it. > > Sorry, I don't virtio internal. please don't ask me. > > > >
--- linux-2.6.orig/drivers/virtio/virtio_balloon.c 2010-10-13 10:14:38.000000000 +0800 +++ linux-2.6/drivers/virtio/virtio_balloon.c 2011-04-26 11:38:43.979785141 +0800 @@ -25,6 +25,7 @@ #include <linux/freezer.h> #include <linux/delay.h> #include <linux/slab.h> +#include <linux/oom.h> struct virtio_balloon { @@ -102,6 +103,7 @@ static void fill_balloon(struct virtio_b /* We can only do one array worth at a time. */ num = min(num, ARRAY_SIZE(vb->pfns)); + oom_killer_disable(); for (vb->num_pfns = 0; vb->num_pfns < num; vb->num_pfns++) { struct page *page = alloc_page(GFP_HIGHUSER | __GFP_NORETRY | __GFP_NOMEMALLOC | __GFP_NOWARN); @@ -119,6 +121,7 @@ static void fill_balloon(struct virtio_b vb->num_pages++; list_add(&page->lru, &vb->pages); } + oom_killer_enable(); /* Didn't get any? Oh well. */ if (vb->num_pfns == 0)
When memory pressure is high, virtio ballooning will probably cause oom killing. Even if alloc_page with GFP_NORETRY itself does not directly trigger oom it will make memory becoming low then memory alloc of other processes will trigger oom killing. It is not desired behaviour. Here disable oom killer in fill_balloon to address this issue. Signed-off-by: Dave Young <hidave.darkstar@gmail.com> --- drivers/virtio/virtio_balloon.c | 3 +++ 1 file changed, 3 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html