linux-kernel - Re: [RFC 2/2] virtio_balloon: 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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 13 May 2013 22:21:17 +0300
From:	"Michael S. Tsirkin" <mst@...hat.com>
To:	Rik van Riel <riel@...hat.com>
Cc:	Luiz Capitulino <lcapitulino@...hat.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	aquini@...hat.com, amit.shah@...hat.com, anton@...msg.org
Subject: Re: [RFC 2/2] virtio_balloon: auto-ballooning support

On Mon, May 13, 2013 at 03:10:19PM -0400, Rik van Riel wrote:
> On 05/13/2013 11:35 AM, Michael S. Tsirkin wrote:
> >On Mon, May 13, 2013 at 11:22:58AM -0400, Rik van Riel wrote:
> 
> >>I believe the Google patches still included some way for the
> >>host to initiate balloon inflation on the guest side, because
> >>the guest internal state alone is not enough to see when the
> >>host is under memory pressure.
> >>
> >>I discussed the project with the Google developers in question
> >>a little over a year ago, but I do not remember whether their
> >>pressure notification went through qemu, or directly from the
> >>host kernel to the guest kernel...
> >
> >So increasing the max number of pages in balloon
> >indicates host memory pressure to the guest?
> >Fair enough but I wonder whether there's a way to
> >make it more explicit in the interface, somehow.
> 
> There may be a better way to do this, but I am really not sure
> what that would be. What properties would you like to see in
> the interface? What kind of behaviour are you looking for?

I'd like to propagate what we know to the guest and
not require things we don't know.

Well for once, all we know is host is under memory pressure.
We don't really know how much memory should be freed.

So maybe we should just have a binary "host under memory
pressure" and have guest free what it can, e.g. have it
drop caches more aggressively.

> -- 
> All rights reversed
--
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/