From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39209) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCnnZ-0005eo-5f for qemu-devel@nongnu.org; Wed, 08 Jul 2015 07:45:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZCnnW-0004Af-DZ for qemu-devel@nongnu.org; Wed, 08 Jul 2015 07:45:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48430) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZCnnW-00049Y-93 for qemu-devel@nongnu.org; Wed, 08 Jul 2015 07:45:54 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 245D4BBF5E for ; Wed, 8 Jul 2015 11:45:53 +0000 (UTC) Date: Wed, 8 Jul 2015 14:45:50 +0300 From: "Michael S. Tsirkin" Message-ID: <20150708144332-mutt-send-email-mst@redhat.com> References: <1436348808-223033-1-git-send-email-imammedo@redhat.com> <20150708125901-mutt-send-email-mst@redhat.com> <20150708134116.0218f4e5@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150708134116.0218f4e5@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [RFC v3 0/8] Fix QEMU crash during memory hotplug with vhost=on List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: pbonzini@redhat.com, qemu-devel@nongnu.org On Wed, Jul 08, 2015 at 01:41:16PM +0200, Igor Mammedov wrote: > As additional issue: > deleting backend doesn't actually frees memory since it's > just mmap(NORESERVE) over allocated region. It's possible > to do madvise(MADV_DONTNEED) on area but it doesn't guaranty > that kernel will free memory. munmap does not guarantee that either. > So all these mmap/remap > tricks could screw up mgmt tools if they try to limit memory > consumed by QEMU. It's likely easier to manage if virtual memory usage does not jump up and down randomly. > series is not tested wrt cross-version migration. Testing is always good but I don't see anything touching migration here. -- MST