From nobody Sun Feb 8 22:43:34 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1502980526261531.1861826705732; Thu, 17 Aug 2017 07:35:26 -0700 (PDT) Received: from localhost ([::1]:55799 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1diLtN-00026i-2v for importer@patchew.org; Thu, 17 Aug 2017 10:35:25 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1diLnT-0005hK-CQ for qemu-devel@nongnu.org; Thu, 17 Aug 2017 10:29:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1diLnQ-0006um-6g for qemu-devel@nongnu.org; Thu, 17 Aug 2017 10:29:19 -0400 Received: from fanzine.igalia.com ([91.117.99.155]:48670) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1diLnP-0006iS-Pa; Thu, 17 Aug 2017 10:29:16 -0400 Received: from a88-114-101-76.elisa-laajakaista.fi ([88.114.101.76] helo=perseus.local) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) id 1diLmn-00044B-24; Thu, 17 Aug 2017 16:28:37 +0200 Received: from berto by perseus.local with local (Exim 4.89) (envelope-from ) id 1diLmZ-0001vy-BX; Thu, 17 Aug 2017 17:28:23 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=References:In-Reply-To:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From; bh=vYXLlm26x4quiIx+vrPnFr4ce7RsOelgS74XahQvaK4=; b=mWOm5E9tZoVNOiKR874+gOXUwgTpPhQA2hDnT9md6Kux+S4rJHUvSQXWb/+XnidGzgrcU6WoCtPiEP09HJgCdzRN67AYGhGlYzO8HPgrUxbp9u/DYDQZEaDootoRLVFXx9U3E5I5I1EjBzahEx+dhZERKy9NScvBe9VM4FZzsY16gEakFj9tHPtWf7klfvaPl2uOyZ2ZqdrFmOzbSFTJtZP0nTeVWfhrnfZDszQVq9wEY9XNUG7tq9NLXMSl7iYwj7bk+yc2pf841qTR/WQtKkgTWZYZi3zF0Qt/3hrvtYPc54kNWDHos1edNW3dcSRgJe02a62FBe7LLT1viDdw8w==; From: Alberto Garcia To: qemu-devel@nongnu.org Date: Thu, 17 Aug 2017 17:28:13 +0300 Message-Id: <5991d93d80c91f41e9ddd682d4d5292e275bbd62.1502979710.git.berto@igalia.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: References: In-Reply-To: References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] [fuzzy] X-Received-From: 91.117.99.155 Subject: [Qemu-devel] [PATCH 2/4] throttle: Update the throttle_fix_bucket() documentation X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alberto Garcia , Stefan Hajnoczi , qemu-block@nongnu.org, Manos Pitsidianakis Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" The way the throttling algorithm works is that requests start being throttled once the bucket level exceeds the burst limit. When we get there the bucket leaks at the level set by the user (bkt->avg), and that leak rate is what prevents guest I/O from exceeding the desired limit. If we don't allow bursts (i.e. bkt->max =3D=3D 0) then we can start throttling requests immediately. The problem with keeping the threshold at 0 is that it only allows one request at a time, and as soon as there's a bit of I/O from the guest every other request will be throttled and performance will suffer considerably. That can even make the guest unable to reach the throttle limit if that limit is high enough, and that happens regardless of the block scheduler used by the guest. Increasing that threshold gives flexibility to the guest, allowing it to perform short bursts of I/O before being throttled. Increasing the threshold too much does not make a difference in the long run (because it's the leak rate what defines the actual throughput) but it does allow the guest to perform longer initial bursts and exceed the throttle limit for a short while. A burst value of bkt->avg / 10 allows the guest to perform 100ms' worth of I/O at the target rate without being throttled. Signed-off-by: Alberto Garcia --- util/throttle.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/util/throttle.c b/util/throttle.c index b2a52b8b34..9a6bda813c 100644 --- a/util/throttle.c +++ b/util/throttle.c @@ -366,14 +366,9 @@ static void throttle_fix_bucket(LeakyBucket *bkt) /* zero bucket level */ bkt->level =3D bkt->burst_level =3D 0; =20 - /* The following is done to cope with the Linux CFQ block scheduler - * which regroup reads and writes by block of 100ms in the guest. - * When they are two process one making reads and one making writes cfq - * make a pattern looking like the following: - * WWWWWWWWWWWRRRRRRRRRRRRRRWWWWWWWWWWWWWwRRRRRRRRRRRRRRRRR - * Having a max burst value of 100ms of the average will help smooth t= he - * throttling - */ + /* If bkt->max is 0 we still want to allow short bursts of I/O + * from the guest, otherwise every other request will be throttled + * and performance will suffer considerably. */ min =3D bkt->avg / 10; if (bkt->avg && !bkt->max) { bkt->max =3D min; --=20 2.11.0