From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2g2R-0005Yn-4p for qemu-devel@nongnu.org; Wed, 10 Jun 2015 09:27:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2g2M-0003fJ-5K for qemu-devel@nongnu.org; Wed, 10 Jun 2015 09:27:27 -0400 Received: from mx2.parallels.com ([199.115.105.18]:36191) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2g2L-0003f5-W9 for qemu-devel@nongnu.org; Wed, 10 Jun 2015 09:27:22 -0400 Message-ID: <55783B2D.2030701@openvz.org> Date: Wed, 10 Jun 2015 16:27:09 +0300 From: "Denis V. Lunev" MIME-Version: 1.0 References: <1433845144-26889-1-git-send-email-den@openvz.org> <1433845144-26889-2-git-send-email-den@openvz.org> <5576C1CF.40305@de.ibm.com> <5578274D.6070900@openvz.org> <20150610151113-mutt-send-email-mst@redhat.com> In-Reply-To: <20150610151113-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/1] balloon: add a feature bit to let Guest OS deflate balloon on oom List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: James.Bottomley@HansenPartnership.com, Christian Borntraeger , qemu-devel@nongnu.org, Raushaniya Maksudova , Anthony Liguori On 10/06/15 16:13, Michael S. Tsirkin wrote: > On Wed, Jun 10, 2015 at 03:02:21PM +0300, Denis V. Lunev wrote: >> On 09/06/15 13:37, Christian Borntraeger wrote: >>> Am 09.06.2015 um 12:19 schrieb Denis V. Lunev: >>>> Excessive virtio_balloon inflation can cause invocation of OOM-killer, >>>> when Linux is under severe memory pressure. Various mechanisms are >>>> responsible for correct virtio_balloon memory management. Nevertheless it >>>> is often the case that these control tools does not have enough time to >>>> react on fast changing memory load. As a result OS runs out of memory and >>>> invokes OOM-killer. The balancing of memory by use of the virtio balloon >>>> should not cause the termination of processes while there are pages in the >>>> balloon. Now there is no way for virtio balloon driver to free memory at >>>> the last moment before some process get killed by OOM-killer. >>>> >>>> This does not provide a security breach as balloon itself is running >>>> inside Guest OS and is working in the cooperation with the host. Thus >>>> some improvements from Guest side should be considered as normal. >>>> >>>> To solve the problem, introduce a virtio_balloon callback which is >>>> expected to be called from the oom notifier call chain in out_of_memory() >>>> function. If virtio balloon could release some memory, it will make the >>>> system return and retry the allocation that forced the out of memory >>>> killer to run. >>>> >>>> This behavior should be enabled if and only if appropriate feature bit >>>> is set on the device. It is off by default. >>> The balloon frees pages in this way >>> >>> static void balloon_page(void *addr, int deflate) >>> { >>> #if defined(__linux__) >>> if (!kvm_enabled() || kvm_has_sync_mmu()) >>> qemu_madvise(addr, TARGET_PAGE_SIZE, >>> deflate ? QEMU_MADV_WILLNEED : QEMU_MADV_DONTNEED); >>> #endif >>> } >>> >>> The guest can re-touch that page and get a empty zero or the old page back without >>> tampering the host integrity. This should work for all cases I am aware of (without sync_mmu its a nop anyway) so why not enable that by default? Anything that I missed? >>> >>> Christian >> I'd like to do that :) Actually original version of kernel patch >> has enabled this unconditionally. But Michael asked to make >> it configurable and off by default. >> >> Den > That's not the question here. The question is why is it limited by kvm_has_sync_mmu. > original comment about this is quite simple " Until 2.6.27, KVM forced memory pinning so we must disable ballooning unless the kernel actually supports it when using KVM. It's always safe when using TCG." Thus this check is a rudiment of a very-very old kernels. Actually I do not know whether current QEMU will start on such kernels :) Den