From patchwork Fri Jan 11 06:37:29 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Guangrong X-Patchwork-Id: 10757471 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 482E41399 for ; Fri, 11 Jan 2019 06:37:56 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 382E429AEC for ; Fri, 11 Jan 2019 06:37:56 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2BDDD29AFF; Fri, 11 Jan 2019 06:37:56 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4AB7329AEC for ; Fri, 11 Jan 2019 06:37:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730236AbfAKGht (ORCPT ); Fri, 11 Jan 2019 01:37:49 -0500 Received: from mail-pg1-f169.google.com ([209.85.215.169]:40087 "EHLO mail-pg1-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725267AbfAKGhs (ORCPT ); Fri, 11 Jan 2019 01:37:48 -0500 Received: by mail-pg1-f169.google.com with SMTP id z10so5907155pgp.7 for ; Thu, 10 Jan 2019 22:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=YWB5ebsLtKqAkrxfbAsNN6bCEGxSWvVRBCXfnTjEnwo=; b=fonA4IZN9R77D7kiSQXX4501xsUSWWl8rWlqmqDjYi2wLvB/48QKIbdpJ8nLXYq8pw UEgLONebeKi6KnordW7u90j8ScyF5QyUXSfShDEUSJzLFbCJfRXjyoewVRjma/uKVOWo 8hlJtQ56gY8+xsQRglkhRf1U/OT4UG5Ujj7ES5sid2W4ZVENFeIyDENYXhYjQiI0/0/+ PLvuHoNhz+SpaLTmR/itMy9SbyDm1AYL0yfYk2Z/OOEB5+dCV14SF7V9Iy7ZUFQewGdd 9bzfdlPByBoIcKYqWaV2KiEjr1nKqSlpDnJJc9vgHg7JOgeeyYq9R91ZIWYvepsEK0Dp AO8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=YWB5ebsLtKqAkrxfbAsNN6bCEGxSWvVRBCXfnTjEnwo=; b=O4LFGbH77gl/g6iuE4T94q8oyREwlAaUdYUgXc9p9znj4DbpbkBkgPZDBTyMDxoaI9 d3BRKhYlUbtiVwBM/7R/W8PlWsd34Zs9ezOeZ3gjZd4a9z42KkZoEjwy0URpgm7+EqAM zh/rC70zjiTwZJvPOYwn5ijc08NBqVerqoilUXFn3wYciIKg/yWVvj554RfIzBpJNQRK eCo4Z/Hjtqxj8ToYJ0T2LSleoVon6+bGYesN3+mty57x476hkVCfRmKGonRDOp3BLmdH FN7bNZ6OAhTftynEiJJyKqei6RWlXjQSQXQbiZ0O+UVPTgIijYz+PytiFeRuV2ut4Tx3 Vp1Q== X-Gm-Message-State: AJcUukfmil8skEKU7Rv77ibtjPDaDM9TgJA9PsgbN/6G8UPiSOr/+tSt G01F62tuLjQ19jS9p88c4B0= X-Google-Smtp-Source: ALg8bN4bxri16pzC/F9hK/sQ+AS7mw1PYv+Ow1hw/fnzS5X4WkXiG0cxGTSKEaPrYBd0ISSY7+mRuQ== X-Received: by 2002:a63:f34b:: with SMTP id t11mr12308569pgj.341.1547188667872; Thu, 10 Jan 2019 22:37:47 -0800 (PST) Received: from localhost.localdomain ([203.205.141.36]) by smtp.gmail.com with ESMTPSA id 78sm141460933pft.184.2019.01.10.22.37.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 10 Jan 2019 22:37:47 -0800 (PST) From: guangrong.xiao@gmail.com X-Google-Original-From: xiaoguangrong@tencent.com To: pbonzini@redhat.com, mst@redhat.com, mtosatti@redhat.com Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, dgilbert@redhat.com, peterx@redhat.com, wei.w.wang@intel.com, eblake@redhat.com, quintela@redhat.com, cota@braap.org, Xiao Guangrong Subject: [PATCH v2 0/3] optimize waiting for free thread to do compression Date: Fri, 11 Jan 2019 14:37:29 +0800 Message-Id: <20190111063732.10484-1-xiaoguangrong@tencent.com> X-Mailer: git-send-email 2.14.5 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Xiao Guangrong Changelog in v2: squash 'compress-wait-thread-adaptive' into 'compress-wait-thread' based on peter's suggestion Currently we have two behaviors if all threads are busy to do compression, the main thread mush wait one of them becoming free if @compress-wait-thread set to on or the main thread can directly return without wait and post the page out as normal one Both of them have its profits and short-comes, however, if the bandwidth is not limited extremely so that compression can not use out all of it bandwidth, at the same time, the migration process is easily throttled if we posted too may pages as normal pages. None of them can work properly under this case In order to use the bandwidth more effectively, we introduce the third behavior, adaptive, which make the main thread wait if there is no bandwidth left or let the page go out as normal page if there has enough bandwidth to make sure the migration process will not be throttled Another patch introduces a new statistic, pages-per-second, as bandwidth or mbps is not enough to measure the performance of posting pages out as we have compression, xbzrle, which can significantly reduce the amount of the data size, instead, pages-per-second is the one we want Performance data ================ We have limited the bandwidth to 300 Used Bandwidth Pages-per-Second compress-wait-thread = on 951.66 mbps 131784 compress-wait-thread = off 2491.74 mbps 93495 compress-wait-thread-adaptive 1982.94 mbps 162529 = on Xiao Guangrong (3): migration: introduce pages-per-second migration: fix memory leak when updating tls-creds and tls-hostname migration: introduce adaptive model for waiting thread hmp.c | 8 ++- migration/migration.c | 137 +++++++++++++++++++++++++++++++++++++++++--------- migration/migration.h | 21 ++++++++ migration/ram.c | 122 ++++++++++++++++++++++++++++++++++++++++---- qapi/migration.json | 44 +++++++++++----- 5 files changed, 281 insertions(+), 51 deletions(-)