linux-kernel - Re: [RFC 2/2] virtio_balloon: add auto-ballooning support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 14 Jan 2013 10:05:01 -0200
From:	Luiz Capitulino <lcapitulino@...hat.com>
To:	Amit Shah <amit.shah@...hat.com>
Cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org, riel@...hat.com,
	aquini@...hat.com, mst@...hat.com, agl@...ibm.com
Subject: Re: [RFC 2/2] virtio_balloon: add auto-ballooning support

On Sat, 12 Jan 2013 02:13:17 +0530
Amit Shah <amit.shah@...hat.com> wrote:

> On (Tue) 18 Dec 2012 [18:17:30], Luiz Capitulino wrote:
> > The auto-ballooning feature automatically performs balloon inflate or
> > deflate based on host and guest memory pressure. This can help to
> > avoid swapping or worse in both, host and guest.
> > 
> > Auto-ballooning has a host and a guest part. The host performs
> > automatic inflate by requesting the guest to inflate its balloon
> > when the host is facing memory pressure. The guest performs
> > automatic deflate when it's facing memory pressure itself. It's
> > expected that auto-inflate and auto-deflate will balance each
> > other over time.
> > 
> > This commit implements the guest side of auto-ballooning.
> > 
> > To perform automatic deflate, the virtio_balloon driver registers
> > a shrinker callback, which will try to deflate the guest's balloon
> > on guest memory pressure just like if it were a cache. The shrinker
> > callback is only registered if the host supports the
> > VIRTIO_BALLOON_F_AUTO_BALLOON feature bit.
> 
> I'm wondering if guest should auto-deflate even when the AUTO_BALLOON
> feature isn't supported by the host: if a guest is under pressure,
> there's no way for it to tell the host and wait for the host to
> deflate the balloon, so it may be beneficial to just go ahead and
> deflate the balloon for all hosts.

I see two problems with this. First, this will automagically override
balloon changes done by the user; and second, if we don't have the
auto-inflate part and if the host starts facing memory pressure, VMs
may start getting OOM.

> Similarly, on the host side, management can configure a VM to either
> enable or disable auto-balloon (the auto-inflate part).  So even the
> host can do away with the feature advertisement and negotiation.
> 
> Is there some use-case I'm missing where doing these actions after
> feature negotiation is beneficial?
> 
> > FIXMEs
> > 
> >  o the guest kernel seems to spin when the host is performing a long
> >    auto-inflate
> 
> Is this introduced by the current patches?  I'd assume it happens even
> without it -- these patches just introduce some heuristics, the
> mechanism has stayed the same.

Good point, I'll check that.

> > Signed-off-by: Luiz Capitulino <lcapitulino@...hat.com>
> > ---
> >  drivers/virtio/virtio_balloon.c     | 54 +++++++++++++++++++++++++++++++++++++
> >  include/uapi/linux/virtio_balloon.h |  1 +
> >  2 files changed, 55 insertions(+)
> 
> Patch looks good, just one thing:
> 
> > +	/*
> > +	 * If the current balloon size is greater than the number of
> > +	 * pages being reclaimed by the kernel, deflate only the needed
> > +	 * amount. Otherwise deflate everything we have.
> > +	 */
> > +	if (nr_pages > sc->nr_to_scan) {
> > +		new_target = nr_pages - sc->nr_to_scan;
> > +	} else {
> > +		new_target = 0;
> > +	}
> 
> This looks better:
> 
> 	new_target = 0;
> 	if (nr_pages > sc->nr_to_scan) {
> 		new_target = nr_pages - sc->nr_to_scan;
> 	}

Ok.

> 
> 
> Thanks,
> 		Amit
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/