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 <[email protected]>
---
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)
> 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 <[email protected]>
> ---
> 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 [email protected]
> 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
<[email protected]> 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 <[email protected]>
>> ---
>> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
>
--
Regards
dave
> On Tue, Apr 26, 2011 at 2:38 PM, KOSAKI Motohiro
> <[email protected]> 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 <[email protected]>
> >> ---
> >> 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.
On Tue, Apr 26, 2011 at 3:22 PM, KOSAKI Motohiro
<[email protected]> wrote:
>> On Tue, Apr 26, 2011 at 2:38 PM, KOSAKI Motohiro
>> <[email protected]> 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 <[email protected]>
>> >> ---
>> >> 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