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:	Sat, 12 Jan 2013 02:13:17 +0530
From:	Amit Shah <amit.shah@...hat.com>
To:	Luiz Capitulino <lcapitulino@...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 (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.

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.

> 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;
	}


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/