From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqIh2-0004kL-Lh for qemu-devel@nongnu.org; Wed, 13 Apr 2016 07:10:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqIgx-0006Fm-Lq for qemu-devel@nongnu.org; Wed, 13 Apr 2016 07:10:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqIgx-0006Fg-6S for qemu-devel@nongnu.org; Wed, 13 Apr 2016 07:10:39 -0400 Date: Wed, 13 Apr 2016 14:10:32 +0300 From: "Michael S. Tsirkin" Message-ID: <20160413111032.GA22137@redhat.com> References: <1459138565-6244-1-git-send-email-jitendra.kolhe@hpe.com> <20160329151921-mutt-send-email-mst@redhat.com> <56FE56AC.8050903@hpe.com> <20160410184239-mutt-send-email-mst@redhat.com> <570E257F.3060205@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <570E257F.3060205@hpe.com> Subject: Re: [Qemu-devel] [PATCH v2] migration: skip sending ram pages released by virtio-balloon driver. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jitendra Kolhe Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, crosthwaite.peter@gmail.com, rth@twiddle.net, eblake@redhat.com, lcapitulino@redhat.com, stefanha@redhat.com, armbru@redhat.com, quintela@redhat.com, den@openvz.org, JBottomley@Odin.com, borntraeger@de.ibm.com, amit.shah@redhat.com, dgilbert@redhat.com, ehabkost@redhat.com, mohan_parthasarathy@hpe.com, simhan@hpe.com On Wed, Apr 13, 2016 at 04:24:55PM +0530, Jitendra Kolhe wrote: > Can we extend support for post-copy in a different patch set? If the optimization does not *help* on some paths, that's fine. The issue is with adding extra code special-casing protocols: + if (migrate_postcopy_ram()) { + balloon_bitmap_disable_state = BALLOON_BITMAP_DISABLE_PERMANENT; + } Generally when one sees that patchset breaks XYZ... the easy solution is "check for XYZ and disable the optimization". But do this enough times and the codebase becomes impossible to reason about. why did migration become slower? oh it enabled optimization A and that conflicts with optimization B ... > and use > current patch set to support other remaining protocols? Even disregarding postcopy, I think there were comments that need to be addressed. -- MST