From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu6wn-00042R-15 for qemu-devel@nongnu.org; Thu, 27 Nov 2014 16:50:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xu6we-0007Qb-Ru for qemu-devel@nongnu.org; Thu, 27 Nov 2014 16:49:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu6we-0007QO-KR for qemu-devel@nongnu.org; Thu, 27 Nov 2014 16:49:48 -0500 Date: Thu, 27 Nov 2014 23:49:43 +0200 From: "Michael S. Tsirkin" Message-ID: <20141127214943.GA26704@redhat.com> References: <1417088742-4538-1-git-send-email-den@openvz.org> <1417088742-4538-3-git-send-email-den@openvz.org> <20141127122814.GA13476@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 2/2] 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: Andrey Korolyov Cc: "Denis V. Lunev" , "qemu-devel@nongnu.org" , Raushaniya Maksudova On Thu, Nov 27, 2014 at 06:00:36PM +0400, Andrey Korolyov wrote: > On Thu, Nov 27, 2014 at 3:28 PM, Michael S. Tsirkin wrote: > > On Thu, Nov 27, 2014 at 03:50:11PM +0400, Andrey Korolyov wrote: > >> On Thu, Nov 27, 2014 at 2:45 PM, Denis V. Lunev wrote: > >> > 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 to 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. > >> > > >> > This functionality was recently merged into vanilla Linux (actually in > >> > linux-next at the moment) > >> > > >> > commit 5a10b7dbf904bfe01bb9fcc6298f7df09eed77d5 > >> > Author: Raushaniya Maksudova > >> > Date: Mon Nov 10 09:36:29 2014 +1030 > >> > > >> > This patch adds respective control bits into QEMU. It introduces > >> > deflate-on-oom option for baloon device which do the trick. > >> > > >> > Signed-off-by: Denis V. Lunev > >> > CC: Raushaniya Maksudova > >> > CC: Anthony Liguori > >> > CC: Michael S. Tsirkin > > > > ... > > > >> Had you tried this with a system-wide OOM on a real workload? This > >> behavior can work perfectly with dedicated memory cgroups, but I`m > >> afraid it would be unusable when entire system stalls and waits for a > >> balloon deflation. > > > > That's really a question about guest drivers though, isn't it? > > So you aren't responding to correct patches, and aren't copying > > the correct people. > > > > -- > > MST > > Not entirely, it is a question about host-guest interaction in such a > case. If we will wait for a balloon deflation while OOM condition > exists at the 'root' cg controller level, for a certain settings it > may probably lead to the host unresponsiveness. As for OOM event in a > dedicated cgroup with strictly defined set of processes inside, it > should way more safe. In other words, even such kind of guest-host > interaction can be considered as a potential threat for a host > security, as return from a try of balloon defiation may take too much > time and some other host processes can be stuck effectively. I am > using delayed OOM loop via userspace application, reaching simular > goals, but it is using dedicated cgroups explicitly. Please correct me > if I am wrong in my suggestions. ATM balloon is cooperative anyway: If guest deflating balloon leads to host OOM, you have misconfigured your host, or you have trusted guests. We could change this: unmap pages from guest memory on inflate, map them back on inflate. -- MST