* [PATCH 1/2] virtio_balloon: disable oom killer when fill balloon
@ 2011-04-26 5:29 Dave Young
2011-04-26 6:38 ` KOSAKI Motohiro
0 siblings, 1 reply; 5+ messages in thread
From: Dave Young @ 2011-04-26 5:29 UTC (permalink / raw)
To: kvm, linux-kernel
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();
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)
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH 1/2] virtio_balloon: disable oom killer when fill balloon 2011-04-26 5:29 [PATCH 1/2] virtio_balloon: disable oom killer when fill balloon Dave Young @ 2011-04-26 6:38 ` KOSAKI Motohiro 2011-04-26 7:09 ` Dave Young 0 siblings, 1 reply; 5+ messages in thread From: KOSAKI Motohiro @ 2011-04-26 6:38 UTC (permalink / raw) To: Dave Young; +Cc: kosaki.motohiro, kvm, linux-kernel > 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/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/2] virtio_balloon: disable oom killer when fill balloon 2011-04-26 6:38 ` KOSAKI Motohiro @ 2011-04-26 7:09 ` Dave Young 2011-04-26 7:22 ` KOSAKI Motohiro 0 siblings, 1 reply; 5+ messages in thread From: Dave Young @ 2011-04-26 7:09 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: kvm, linux-kernel 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/ > > > > -- Regards dave ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/2] virtio_balloon: disable oom killer when fill balloon 2011-04-26 7:09 ` Dave Young @ 2011-04-26 7:22 ` KOSAKI Motohiro 2011-04-26 8:47 ` Dave Young 0 siblings, 1 reply; 5+ messages in thread From: KOSAKI Motohiro @ 2011-04-26 7:22 UTC (permalink / raw) To: Dave Young; +Cc: kosaki.motohiro, kvm, linux-kernel > 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/2] virtio_balloon: disable oom killer when fill balloon 2011-04-26 7:22 ` KOSAKI Motohiro @ 2011-04-26 8:47 ` Dave Young 0 siblings, 0 replies; 5+ messages in thread From: Dave Young @ 2011-04-26 8:47 UTC (permalink / raw) To: KOSAKI Motohiro; +Cc: kvm, linux-kernel 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. > > > > -- Regards dave ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-04-26 8:47 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-04-26 5:29 [PATCH 1/2] virtio_balloon: disable oom killer when fill balloon Dave Young 2011-04-26 6:38 ` KOSAKI Motohiro 2011-04-26 7:09 ` Dave Young 2011-04-26 7:22 ` KOSAKI Motohiro 2011-04-26 8:47 ` Dave Young
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.