linux-kernel - Re: [PATCH 6/9] VMware balloon: Do not limit the amount of frees and allocations in non-sleep mode.

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]

Message-ID: <1434121617.25956.60.camel@vmware.com>
Date:	Fri, 12 Jun 2015 15:06:56 +0000
From:	Philip Moltmann <moltmann@...are.com>
To:	"dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"pv-drivers@...are.com" <pv-drivers@...are.com>,
	Xavier Deguillard <xdeguillard@...are.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH 6/9] VMware balloon: Do not limit the amount of frees
 and allocations in non-sleep mode.

Hi,

thanks for taking so much interest in this driver. It is quite good
that our design choices get scrutinized by non-current VMware
employees.


> I understand that you negotiate the capabilities between hypervisor 
> and
> the balloon driver, however that was not my concern (and I am sorry 
> that
> I did not express it properly).
> 
> The patch description stated:
> 
> "Before this patch the slow memory transfer would cause the 
> destination
> VM to have internal swapping until all memory is transferred. Now the
> memory is transferred fast enough so that the destination VM does not
> swap."
> 
> As far as I understand the improvements in memory transfer speed 
> hinge
> on the availability of batched operations, you however remove the 
> limits
> on non-sleep allocations unconditionally. Thus my question: on older
> ESXi's that do not support batcher operations won't this cause VM to
> start swapping?

Three improvements contribute to the overall faster speed:
- batched operations reduce the hypervisor overhead per page
- 2m instead of 4k buffer reduce the hypervisor overhead per page
- removing the rate-limiting for non-sleep allocations allows the guest
operating system to reclaim memory as fast as it can instead of
artificially limiting it.

Any of these improvements is great by itself and helps a lot. The
combination of all three makes a rather dramatic difference.

We cause hypervisor-level swapping if the balloon driver does not
reclaim fast enough. As any of these improvements increases reclamation
speed, we reduce swapping risk in any case.

Unfortunately the first two improvements rely on hypervisor support,
the last does not.

Thanks
Philip