From patchwork Thu Dec 13 07:57:25 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Xiao Guangrong X-Patchwork-Id: 10728123 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 78BAB14BD for ; Thu, 13 Dec 2018 07:57:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6C30729DDD for ; Thu, 13 Dec 2018 07:57:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5FBF629E4D; Thu, 13 Dec 2018 07:57:40 +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 C1A9829DDD for ; Thu, 13 Dec 2018 07:57:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727134AbeLMH5i (ORCPT ); Thu, 13 Dec 2018 02:57:38 -0500 Received: from mail-pl1-f196.google.com ([209.85.214.196]:33574 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726500AbeLMH5i (ORCPT ); Thu, 13 Dec 2018 02:57:38 -0500 Received: by mail-pl1-f196.google.com with SMTP id z23so683609plo.0 for ; Wed, 12 Dec 2018 23:57:38 -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=+usJZdMS1lA1aoaksKsSdXTm5hdboDDv7Gdwa+B6S8M=; b=Vajf1Dkz/e3L4fLGQiuD9SMh84oxIC0SLB7adq3nn6zw8OensQmrnINDMjXxrHPd5d ei8PnpkjOWmJee8teKGTMF7m2xtNZquJnyhLuh7p7iUZXMr5/gqLr0dAkXAheU2ETqp+ PkeK3Qpd+mNXQf5lCvpZkti5qKaUG4w+1L7uoMwNTyJ/QDwdauRPy53tGDZtvbpe17BQ TPmmn5Zz9NhRs3hbMd7kU1W7OYBMMUOCKODlAJmCS05mas5sKjrgClXQ7C6Fq/cW9kPn wZ0Yyo3dwI2NwaFXwJx3bAHdIT/6fLTfpQlpwaj75sOOkRUDTJlydigGx0WYJ1r1aorL I6Zg== 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=+usJZdMS1lA1aoaksKsSdXTm5hdboDDv7Gdwa+B6S8M=; b=IxjlG8CbflEWmc9X5ScTbqx9D4rsfi5Ov+g/i7hl44d8NiLtMOxs+gOstyUB5CbV4X o4mcSbGgCOAotYc5W5SaHsWYP9lcpmf2kpxdQS6MbCYC1mzmEZ45okGVOUn5FffP2K1a bdyYv0qcHTLzbqdaYAAiWPBnIjvH5RC/JimIrMxzrG9oanUfr0/P2l7chUUHtzvfbZss vO9VPwUFNlqVhIMKQsW7PNPjGP7hfXcjhqRHC3RW40pSEynt1nq1IoNINDdSVhVajqpT gOHHMHPQAGf8KIUHZglaZ1X34spKpuV7V2EbEifZKcsZ8yCxjFGdt6GmjWGHoWDIEuyQ Q1Tg== X-Gm-Message-State: AA+aEWZtXzl3Y+9/IMv4jV3brB6VRhsB+FfTWJvz22JbxzubJ8sCNUMh 5rSUE+LS0lorv3ipI3h9Wk0= X-Google-Smtp-Source: AFSGD/UWwTYT5YH5RrqdoiUQBR0HAlm47MkysueDyJT/KCWpsr5hC43SyZH+yaOXFH+D1pCj+TS7MA== X-Received: by 2002:a17:902:8d95:: with SMTP id v21mr22705002plo.162.1544687857754; Wed, 12 Dec 2018 23:57:37 -0800 (PST) Received: from localhost.localdomain ([203.205.141.36]) by smtp.gmail.com with ESMTPSA id h19sm1423618pfn.114.2018.12.12.23.57.34 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Dec 2018 23:57:37 -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 0/2] optimize waiting for free thread to do compression Date: Thu, 13 Dec 2018 15:57:25 +0800 Message-Id: <20181213075727.23540-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 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, compress-wait-thread-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 if 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 (2): migration: introduce compress-wait-thread-adaptive migration: introduce pages-per-second hmp.c | 13 ++++++ migration/migration.c | 49 +++++++++++++++++++- migration/migration.h | 12 +++++ migration/ram.c | 124 ++++++++++++++++++++++++++++++++++++++++++++++---- qapi/migration.json | 31 +++++++++++-- 5 files changed, 215 insertions(+), 14 deletions(-)