From nobody Thu May 1 00:43:05 2025
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;
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: <qemu-devel-bounces+importer=patchew.org@nongnu.org>
Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by
mx.zohomail.com
with SMTPS id 1504167863204267.19460171313415;
Thu, 31 Aug 2017 01:24:23 -0700 (PDT)
Received: from localhost ([::1]:54474 helo=lists.gnu.org)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <qemu-devel-bounces+importer=patchew.org@nongnu.org>)
id 1dnKlx-0006JA-3T
for importer@patchew.org; Thu, 31 Aug 2017 04:24:21 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42446)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <stefanha@redhat.com>) id 1dnKkA-0005GQ-BC
for qemu-devel@nongnu.org; Thu, 31 Aug 2017 04:22:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <stefanha@redhat.com>) id 1dnKk6-0005pL-CW
for qemu-devel@nongnu.org; Thu, 31 Aug 2017 04:22:30 -0400
Received: from mx1.redhat.com ([209.132.183.28]:50798)
by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
(Exim 4.71) (envelope-from <stefanha@redhat.com>) id 1dnKk6-0005ot-49
for qemu-devel@nongnu.org; Thu, 31 Aug 2017 04:22:26 -0400
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com
[10.5.11.12])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mx1.redhat.com (Postfix) with ESMTPS id 493C4C0546E1;
Thu, 31 Aug 2017 08:22:25 +0000 (UTC)
Received: from localhost (ovpn-117-89.ams2.redhat.com [10.36.117.89])
by smtp.corp.redhat.com (Postfix) with ESMTP id 61275B2415;
Thu, 31 Aug 2017 08:22:22 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 493C4C0546E1
Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com;
dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com;
spf=fail smtp.mailfrom=stefanha@redhat.com
From: Stefan Hajnoczi <stefanha@redhat.com>
To: <qemu-devel@nongnu.org>
Date: Thu, 31 Aug 2017 09:21:58 +0100
Message-Id: <20170831082210.8362-4-stefanha@redhat.com>
In-Reply-To: <20170831082210.8362-1-stefanha@redhat.com>
References: <20170831082210.8362-1-stefanha@redhat.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
(mx1.redhat.com [10.5.110.32]);
Thu, 31 Aug 2017 08:22:25 +0000 (UTC)
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
[fuzzy]
X-Received-From: 209.132.183.28
Subject: [Qemu-devel] [PULL for-2.10 03/15] throttle: Update the
throttle_fix_bucket() documentation
X-BeenThere: qemu-devel@nongnu.org
X-Mailman-Version: 2.1.21
Precedence: list
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>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Alberto Garcia <berto@igalia.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org
Sender: "Qemu-devel" <qemu-devel-bounces+importer=patchew.org@nongnu.org>
X-ZohoMail: RSF_0 Z_629925259 SPT_0
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: Alberto Garcia <berto@igalia.com>
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 <berto@igalia.com>
Message-id: 31aae6645f0d1fbf3860fb2b528b757236f0c0a7.1503580370.git.berto@i=
galia.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
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.13.5