From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58160)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZrNwx-0007fg-Ph
	for qemu-devel@nongnu.org; Wed, 28 Oct 2015 06:27:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZrNws-0004Gc-OG
	for qemu-devel@nongnu.org; Wed, 28 Oct 2015 06:27:23 -0400
Received: from mailout1.w1.samsung.com ([210.118.77.11]:23461)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZrNws-0004GY-Ih
	for qemu-devel@nongnu.org; Wed, 28 Oct 2015 06:27:18 -0400
Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245])
	by mailout1.w1.samsung.com
	(Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5
	2014)) with ESMTP id <0NWX00059EDG5S90@mailout1.w1.samsung.com> for
	qemu-devel@nongnu.org; Wed, 28 Oct 2015 10:27:16 +0000 (GMT)
From: Pavel Fedin <p.fedin@samsung.com>
References: <012c01d110a6$cd61cf90$68256eb0$@samsung.com>
	<87k2q8e8d4.fsf@neno.neno>
	<002b01d110c0$4a5c8e40$df15aac0$@samsung.com>
	<877fm7b9h2.fsf@neno.neno>
In-reply-to: <877fm7b9h2.fsf@neno.neno>
Date: Wed, 28 Oct 2015 13:27:15 +0300
Message-id: <004b01d1116b$3769aba0$a63d02e0$@samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Content-language: ru
Subject: Re: [Qemu-devel] [PATCH]
	migration:	Introduce	migration_in_completion()
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: quintela@redhat.com
Cc: 'Amit Shah' <amit.shah@redhat.com>, qemu-devel@nongnu.org, 'Luiz Capitulino' <lcapitulino@redhat.com>

 Hello!

> Power people have a similar problem with its hashed page tables, they
> integrated their own save_live implementation because they are too big
> for the last stage.  You can look there for inspiration.

 Hm, i'll take a look...

> How big are we talking here?

 Tables are normally large (about 640K on my VM), but extremely sparse. So the actually modified space during this callback would be
several pages, unlikely more.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia