From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aw5i2-0000Wf-G9 for qemu-devel@nongnu.org; Fri, 29 Apr 2016 06:31:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aw5hq-0004MI-N4 for qemu-devel@nongnu.org; Fri, 29 Apr 2016 06:31:37 -0400 Received: from g1t6214.austin.hp.com ([15.73.96.122]:43250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aw5hq-0004IK-He for qemu-devel@nongnu.org; Fri, 29 Apr 2016 06:31:30 -0400 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> <20160413111032.GA22137@redhat.com> <20160413111538.GA6367@work-vm> <20160413142542-mutt-send-email-mst@redhat.com> From: Jitendra Kolhe Message-ID: <572337E8.10604@hpe.com> Date: Fri, 29 Apr 2016 16:01:04 +0530 MIME-Version: 1.0 In-Reply-To: <20160413142542-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: "Michael S. Tsirkin" , "Dr. David Alan Gilbert" 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, ehabkost@redhat.com, mohan_parthasarathy@hpe.com, simhan@hpe.com On 4/13/2016 5:06 PM, Michael S. Tsirkin wrote: > On Wed, Apr 13, 2016 at 12:15:38PM +0100, Dr. David Alan Gilbert wrote: >> * Michael S. Tsirkin (mst@redhat.com) wrote: >>> 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 =3D BALLOON_BITMAP_DISABLE_PERM= ANENT; >>> + } >>> >>> 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 ... Ok, I understand the confusion caused by such checks. Will remove=20 the migration_postcopy checks from the patch and make sure things=20 don=E2=80=99t break in postcopy path. >> >> Hang on; this is getting all very complicated; I wouldn't start tieing >> this thing up with postcopy yet. Lets try and keep this simple for st= arters. >> >> Dave >=20 > Absolutely, but I don't understand why is this implemented in such > a complex way. > 1. keep track of pages in balloon in a bitmap > 2. put bitmap in a ram block > 3. check that before sending page. if there - it's a zero page >=20 Thanks for the suggestion, putting bitmap in ramblock does remove the code for migrating and dirty page tracking of balloon bitmap pages itself= . In case, the feature is turned-off, the balloon bitmap ramblock is resize= d to 0 to make sure that the bitmap is not migrated to reduce the overhead. > All the complexity is to avoid migrating an extra bit per page > and it seems like a premature optimization to me at this stage. >=20 Major benefit of the optimization is to avoid zero page scan for ballooned out pages. Skipping migrating extra bit per ballooned out=20 page is just an add-on benefit without any overhead as long as it=20 doesn=E2=80=99t break any protocol.=20 Thanks, - Jitendra >>> >>> >>>> and use=20 >>>> current patch set to support other remaining protocols? >>> >>> Even disregarding postcopy, I think there were >>> comments that need to be addressed. >>> >>> --=20 >>> MST >> -- >> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK