svn commit: r267858 - in head/sys/dev: virtio/balloon xen/balloon

[Alan Cox]

On 06/25/2014 08:29, Roger Pau Monné wrote:
> On 25/06/14 13:58, Attilio Rao wrote:
>> On Wed, Jun 25, 2014 at 11:51 AM, Roger Pau Monné <royger at freebsd.org> wrote:
>>> Author: royger
>>> Date: Wed Jun 25 09:51:08 2014
>>> New Revision: 267858
>>> URL: http://svnweb.freebsd.org/changeset/base/267858
>>>
>>> Log:
>>>   xen/virtio: fix balloon drivers to not mark pages as WIRED
>>>
>>>   Prevent the Xen and VirtIO balloon drivers from marking pages as
>>>   wired. This prevents them from increasing the system wired page count,
>>>   which can lead to mlock failing because of hitting the limit in
>>>   vm.max_wired.
>> This change is conceptually wrong.
>> The pages balloon is allocating are unmanaged and they should be wired
>> by definition. Alan and I are considering enforcing this (mandatory
>> wired pages for unmanaged pages allocation) directly in the KPI.
>> This in practice just seem an artifact to deal with scarce  wired
>> memory limit. I suggest that for the XEN case this limit gets bumped
>> rather relying on similar type of hacks.
> IMHO, marking them as wired seems wrong too, those pages are not wired,
> they are simply not there any more. This was discussed in:
>
> http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002643.html
>
> If there's consensus I will revert the change, but I would say that
> increasing vm.max_wired for VMs is also a gross hack.

We wouldn't be changing it just for VMs.  Our current definition of
vm_max_wired dates back to r5455, or in human years 1995.  If the ZFS
ARC has taught us anything, we, or really the page daemon, can cope with
having more than 1/3 of a machine's pages wired.  :-)

I have a couple questions for you.  Exactly how much memory will Xen try
to steal from a domain via ballooning?  Clearly the domain can fail to
respond to the balloon request and Xen has to cope with that.  Can the
domain also explicitly say, "No, I'm not giving you any pages."