From patchwork Tue Nov 19 05:18:39 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 179696 Delivered-To: patch@linaro.org Received: by 2002:a92:38d5:0:0:0:0:0 with SMTP id g82csp168305ilf; Mon, 18 Nov 2019 21:49:16 -0800 (PST) X-Google-Smtp-Source: APXvYqzy6vfsJNDoLTKTK/kxxPUL2gF1K6XhNR8hef0pwnf9boIFeDqgr56/5eI4TiINbyr04B9I X-Received: by 2002:a17:906:1805:: with SMTP id v5mr33182670eje.45.1574142556131; Mon, 18 Nov 2019 21:49:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574142556; cv=none; d=google.com; s=arc-20160816; b=0p4zxiZ2CKIfz7VF3PqtaetDhuaSrJLKeyMlrzN1zxgqAH5M6KiJZ+zjDt5QUk4DY1 +XR1AFUK3BlKUPxWzT2UuD999fp0aJLYWQmFCE9YyfuYBQQKqLsn41l2yDbusffH+vSe Q+T/0Vzo17zYaGuNKeZ7G/xwttN+OD/clQ0wIvBefC/IUPc+1Qwipu4mfl/OVZcPR/lw lBjAoSO1O6U2u76Dneqq2IpjAGDCtzQ2s5GPMvBAx4JnphaEZ+q/kLPCIMNMZhN/6eVT VtB3g42zI9pa1nqNvdMB+rPYOqvFVs1/jtxo+lklQjJe8k4aH4cP8rHzfRjHZnCbDCFt cRlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=gIJmlqeaFbIk5aH2qaOZ0B8T0KXtfRPqZJJ4cfDpzTY=; b=C8kA7aBKfVscQTGP44PpT3c3aHOIxEPzjUYHAG2558cl4TtiKRO2V2to0kUd70YGAY WSusKKiLRofira0nQMOM4ObEXUwv8XEXfsVXT1L1ROlzP6YZy0VxIbVYeN1Q2oukP266 YQSTObBfbL4bfj+MZI8TI+GdvAVpmhuXtEQOPKQdaHuy6s/zhQ38RB6vrjWd1KsuzbxI V/M2fq/K/F5nzasOAjKRxY0dWndOg9G9CGgwBTCQuH3WfX/oA6Lrp7F4BZl/qYrF42aq qiJW+yHpW1ZuHD/nlTy057rl4PpUwaLp3J2uKFao8QzXdQgC1gKt2Oa0l6QBk59ZPjlV zwQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=RBygYwKI; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id hh7si13172476ejb.57.2019.11.18.21.49.15; Mon, 18 Nov 2019 21:49:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=RBygYwKI; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730549AbfKSFtO (ORCPT + 15 others); Tue, 19 Nov 2019 00:49:14 -0500 Received: from mail.kernel.org ([198.145.29.99]:45888 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730779AbfKSFtN (ORCPT ); Tue, 19 Nov 2019 00:49:13 -0500 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 58A37208C3; Tue, 19 Nov 2019 05:49:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574142552; bh=XTKduqN7mHhES6KQ6cLQz/6SZSC+gMKdX1Jkj9OtVMY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RBygYwKIw7oruLMZG0sFuS1arLj77J93Rn387YR6+nBDs+gytXaX053q8K6oGZYi4 T/kufXkaCqS/GdsSnO3QvFjlTpeVvh6QHWvGlaAMI3XN6G4jjdFP8geXYIwXoV5FKQ se9agfvqfDlycFArCuU/Ehz93dhcQQWCQ/p4LWb0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Paolo Valente , Jens Axboe , Sasha Levin Subject: [PATCH 4.14 119/239] blok, bfq: do not plug I/O if all queues are weight-raised Date: Tue, 19 Nov 2019 06:18:39 +0100 Message-Id: <20191119051329.460723697@linuxfoundation.org> X-Mailer: git-send-email 2.24.0 In-Reply-To: <20191119051255.850204959@linuxfoundation.org> References: <20191119051255.850204959@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Paolo Valente [ Upstream commit c8765de0adfcaaf4ffb2d951e07444f00ffa9453 ] To reduce latency for interactive and soft real-time applications, bfq privileges the bfq_queues containing the I/O of these applications. These privileged queues, referred-to as weight-raised queues, get a much higher share of the device throughput w.r.t. non-privileged queues. To preserve this higher share, the I/O of any non-weight-raised queue must be plugged whenever a sync weight-raised queue, while being served, remains temporarily empty. To attain this goal, bfq simply plugs any I/O (from any queue), if a sync weight-raised queue remains empty while in service. Unfortunately, this plugging typically lowers throughput with random I/O, on devices with internal queueing (because it reduces the filling level of the internal queues of the device). This commit addresses this issue by restricting the cases where plugging is performed: if a sync weight-raised queue remains empty while in service, then I/O plugging is performed only if some of the active bfq_queues are *not* weight-raised (which is actually the only circumstance where plugging is needed to preserve the higher share of the throughput of weight-raised queues). This restriction proved able to boost throughput in really many use cases needing only maximum throughput. Signed-off-by: Paolo Valente Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- block/bfq-iosched.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) -- 2.20.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index e65b0da1007b4..93863c6173e66 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -3314,7 +3314,12 @@ static bool bfq_bfqq_may_idle(struct bfq_queue *bfqq) * whether bfqq is being weight-raised, because * bfq_symmetric_scenario() does not take into account also * weight-raised queues (see comments on - * bfq_weights_tree_add()). + * bfq_weights_tree_add()). In particular, if bfqq is being + * weight-raised, it is important to idle only if there are + * other, non-weight-raised queues that may steal throughput + * to bfqq. Actually, we should be even more precise, and + * differentiate between interactive weight raising and + * soft real-time weight raising. * * As a side note, it is worth considering that the above * device-idling countermeasures may however fail in the @@ -3326,7 +3331,8 @@ static bool bfq_bfqq_may_idle(struct bfq_queue *bfqq) * to let requests be served in the desired order until all * the requests already queued in the device have been served. */ - asymmetric_scenario = bfqq->wr_coeff > 1 || + asymmetric_scenario = (bfqq->wr_coeff > 1 && + bfqd->wr_busy_queues < bfqd->busy_queues) || !bfq_symmetric_scenario(bfqd); /*