From patchwork Mon Nov 25 13:36:32 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yury Kotov X-Patchwork-Id: 11260415 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 145976C1 for ; Mon, 25 Nov 2019 13:39:14 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 91444207FD for ; Mon, 25 Nov 2019 13:39:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b="KRVQGv/E" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 91444207FD Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=yandex-team.ru Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Received: from localhost ([::1]:44040 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZEa8-0000nU-9n for patchwork-qemu-devel@patchwork.kernel.org; Mon, 25 Nov 2019 08:39:12 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43697) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iZEXt-00084h-0L for qemu-devel@nongnu.org; Mon, 25 Nov 2019 08:36:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iZEXq-0006uQ-0R for qemu-devel@nongnu.org; Mon, 25 Nov 2019 08:36:50 -0500 Received: from forwardcorp1o.mail.yandex.net ([2a02:6b8:0:1a2d::193]:33210) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iZEXp-0006tG-E9 for qemu-devel@nongnu.org; Mon, 25 Nov 2019 08:36:49 -0500 Received: from mxbackcorp1j.mail.yandex.net (mxbackcorp1j.mail.yandex.net [IPv6:2a02:6b8:0:1619::162]) by forwardcorp1o.mail.yandex.net (Yandex) with ESMTP id EB5672E0DE7; Mon, 25 Nov 2019 16:36:43 +0300 (MSK) Received: from vla1-5826f599457c.qloud-c.yandex.net (vla1-5826f599457c.qloud-c.yandex.net [2a02:6b8:c0d:35a1:0:640:5826:f599]) by mxbackcorp1j.mail.yandex.net (mxbackcorp/Yandex) with ESMTP id PU0MfHJQtw-ahTu8wpR; Mon, 25 Nov 2019 16:36:43 +0300 Precedence: bulk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1574689003; bh=aoBtHArJpFwmHCpsXY9yY1bxvicpSwutbokjRF5oxLw=; h=Message-Id:Date:Subject:To:From:Cc; b=KRVQGv/Edd2sRax95/v6riJp/7YwQDnER6tADXujT+TsL+fe9jl+amEuJ6zWuutV3 SeWADCSirNWs8mCiflKpQ71c1zKOnjeltAtEuutO7IwZfm/3bvjuISfybHDGv+YkVo 6d12aWiFomAeggB/gea0qQMcaTKcQafD/IbPZz1A= Authentication-Results: mxbackcorp1j.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from dynamic-red.dhcp.yndx.net (dynamic-red.dhcp.yndx.net [2a02:6b8:0:408:bc57:f91d:ee50:9634]) by vla1-5826f599457c.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id V5h9BV3y9q-ahWa8dRZ; Mon, 25 Nov 2019 16:36:43 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) From: Yury Kotov To: qemu-devel@nongnu.org (open list:All patches CC here) Subject: [PATCH v2] migration/ram: Yield periodically to the main loop Date: Mon, 25 Nov 2019 16:36:32 +0300 Message-Id: <20191125133632.21387-1-yury-kotov@yandex-team.ru> X-Mailer: git-send-email 2.24.0 MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a02:6b8:0:1a2d::193 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "Dr. David Alan Gilbert" , yc-core@yandex-team.ru, Juan Quintela Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" Usually, incoming migration coroutine yields to the main loop while its IO-channel is waiting for data to receive. But there is a case when RAM migration and data receive have the same speed: VM with huge zeroed RAM. In this case, IO-channel won't read and thus the main loop is stuck and for instance, it doesn't respond to QMP commands. For this case, yield periodically, but not too often, so as not to affect the speed of migration. Signed-off-by: Yury Kotov Reviewed-by: Juan Quintela --- migration/ram.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/migration/ram.c b/migration/ram.c index 5078f94490..9694ee7a0b 100644 --- a/migration/ram.c +++ b/migration/ram.c @@ -4227,7 +4227,7 @@ static void colo_flush_ram_cache(void) */ static int ram_load_precopy(QEMUFile *f) { - int flags = 0, ret = 0, invalid_flags = 0, len = 0; + int flags = 0, ret = 0, invalid_flags = 0, len = 0, i = 0; /* ADVISE is earlier, it shows the source has the postcopy capability on */ bool postcopy_advised = postcopy_is_advised(); if (!migrate_use_compression()) { @@ -4239,6 +4239,17 @@ static int ram_load_precopy(QEMUFile *f) void *host = NULL; uint8_t ch; + /* + * Yield periodically to let main loop run, but an iteration of + * the main loop is expensive, so do it each some iterations + */ + if ((i & 32767) == 0 && qemu_in_coroutine()) { + aio_co_schedule(qemu_get_current_aio_context(), + qemu_coroutine_self()); + qemu_coroutine_yield(); + } + i++; + addr = qemu_get_be64(f); flags = addr & ~TARGET_PAGE_MASK; addr &= TARGET_PAGE_MASK;