From patchwork Tue Jan 29 11:06:25 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 156970 Delivered-To: patch@linaro.org Received: by 2002:a02:48:0:0:0:0:0 with SMTP id 69csp4523594jaa; Tue, 29 Jan 2019 03:08:08 -0800 (PST) X-Google-Smtp-Source: ALg8bN570pR7IQI7ai1vdQW8eHhjcK+tLILAa5uTEFx/E/d8FjzpegCNqRfW33iDZAnrAarN7bx0 X-Received: by 2002:a63:4948:: with SMTP id y8mr23239178pgk.32.1548760088202; Tue, 29 Jan 2019 03:08:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548760088; cv=none; d=google.com; s=arc-20160816; b=aTrhJkwqtwQhA+qiiKn+i3+5Uw0Q6bRjslvC6ve7zek1l9SIGF+iey4rZH2zvR76AN Qi7TEhf5W5uFd8jr+3lhSzObyGq9eJ8H+D5UC4yhMp106iAUbE+fsXyZr/pHZs97tPEi D4JX04PdzN/t3JNrf3svHlnhEHMbgWBm4wZbbpy16xEJC+AlMjf+k6p7LnNlhFsjsTe9 vmJSTQcQrIgVMgRLoT1PqTd2B7cGsXEQR1gQsYlGgziPj9b432oZIqkARyPALdx2yxgj X7058fbyywHmWhQBISBG1oHPLELN951ziGt9tZS4MDGKEVlYQDzHv6LkFJ22YW0l3ydF eF7A== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=KqztSqIPzKKBWIFY2MqAio0w3pO/+CETJ20qHxYP8sU=; b=bhXSVw6oxdgj+xNW2PWauB3U4Fwkq6/A1MzHYo75gjGx+onlCEqrbbNKXjii4fRxbc n++/P7EiJzetrRMqDOIJBwu8vWlpijMtqNnzWfcai75QVmHzurBJHnqUmmfdq1NyzaXu NxKZY3w3tKKwVJpPO0TIY3PnNhEQC8PgrB+PjtpDomM9Ds047M8LnCBhkYyV78CrOWdD +byK5vOHF2xq5FRdobdMk/I2OBh0PXHL5hBJcx35TJSpvCnEEG/uRIGcNTvo4pe0TsDL EwLC2vOo5IPWK/chgNun7sdqRfsSzLwNt/z5C0y05BTCphxvMHSTlYfZogTda67tqgua 9TBQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="dtSOU/Wk"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c4si3361454pfi.110.2019.01.29.03.08.07; Tue, 29 Jan 2019 03:08:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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=@linaro.org header.s=google header.b="dtSOU/Wk"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728026AbfA2LHF (ORCPT + 31 others); Tue, 29 Jan 2019 06:07:05 -0500 Received: from mail-wm1-f65.google.com ([209.85.128.65]:37843 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726893AbfA2LHB (ORCPT ); Tue, 29 Jan 2019 06:07:01 -0500 Received: by mail-wm1-f65.google.com with SMTP id g67so17260894wmd.2 for ; Tue, 29 Jan 2019 03:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=KqztSqIPzKKBWIFY2MqAio0w3pO/+CETJ20qHxYP8sU=; b=dtSOU/WkVIhSYUqeW3JTn3QUufABzxHPLxowScogLO1dE4ZwITfBQdRm0f+ZtddNKB UXUi1A/1zNrj6MnKUUu6LpqcGQ1WdyfuVgpmnqma4bCJGWtcxZaEfLgdfbanuGNMHgWo vhkVrylJKJu+zYCvMj/ntuM4/9rogp/gl39Lk= 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=KqztSqIPzKKBWIFY2MqAio0w3pO/+CETJ20qHxYP8sU=; b=JLOuJn9TGrvoRmlFYHxHUKB5sjjks4jJOBX9exDsRzzlIBXeQ6fmQqbqVLuFYCQRTl hbbqDegRWJtIR+1LG3qMF7mVHrN0rAMRnQKViTzOS7W45hrBfn+sP/s017LDuQsoXQV8 wWzYbdirXvTAOQ3y3Nm/CH40D8AHVMCbbtN0nmLCyKdFzk9eaRFrFcJ3e5KL+FdeiLhb ZrOO0awaRS378kPRvGPQOetn+hpQHOhRw6XnkIvEK1PTpgyrCDv6lG3bV55aBeUAWRyO D8orWA/fcSH4um2Xs0goKRfX1dKrkIZNofUrynJXSXoGP9stjsrt34DeeAyebMYBICBb 80KQ== X-Gm-Message-State: AJcUukfqXGzfgLebIfYdXZfPbBO26oGf0tfCCwoK9xVkBgX+QomtaBJE f7Ip4E+TgqpF77eonoystcTkVA== X-Received: by 2002:a1c:c87:: with SMTP id 129mr19704056wmm.116.1548760018406; Tue, 29 Jan 2019 03:06:58 -0800 (PST) Received: from localhost.localdomain ([88.147.67.218]) by smtp.gmail.com with ESMTPSA id s132sm2066112wmf.28.2019.01.29.03.06.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 03:06:57 -0800 (PST) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, linus.walleij@linaro.org, broonie@kernel.org, bfq-iosched@googlegroups.com, oleksandr@natalenko.name, mancha@tower-research.com, Paolo Valente Subject: [PATCH BUGFIX IMPROVEMENT 01/14] block, bfq: do not consider interactive queues in srt filtering Date: Tue, 29 Jan 2019 12:06:25 +0100 Message-Id: <20190129110638.12652-2-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190129110638.12652-1-paolo.valente@linaro.org> References: <20190129110638.12652-1-paolo.valente@linaro.org> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The speed at which a bfq_queue receives I/O is one of the parameters by which bfq decides whether the queue is soft real-time (i.e., whether the queue contains the I/O of a soft real-time application). In particular, when a bfq_queue remains without outstanding I/O requests, bfq computes the minimum time instant, named soft_rt_next_start, at which the next request of the queue may arrive for the queue to be deemed as soft real time. Unfortunately this filtering may cause problems with a queue in interactive weight raising. In fact, such a queue may be conveying the I/O needed to load a soft real-time application. The latter will actually exhibit a soft real-time I/O pattern after it finally starts doing its job. But, if soft_rt_next_start is updated for an interactive bfq_queue, and the queue has received a lot of service before remaining with no outstanding request (likely to happen on a fast device), then soft_rt_next_start is assigned such a high value that, for a very long time, the queue is prevented from being possibly considered as soft real time. This commit removes the updating of soft_rt_next_start for bfq_queues in interactive weight raising. Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 39 +++++++++++++++++++++++++++++---------- 1 file changed, 29 insertions(+), 10 deletions(-) -- 2.20.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index cd307767a134..c7a4a15c7c19 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -3274,16 +3274,32 @@ void bfq_bfqq_expire(struct bfq_data *bfqd, * requests, then the request pattern is isochronous * (see the comments on the function * bfq_bfqq_softrt_next_start()). Thus we can compute - * soft_rt_next_start. If, instead, the queue still - * has outstanding requests, then we have to wait for - * the completion of all the outstanding requests to - * discover whether the request pattern is actually - * isochronous. + * soft_rt_next_start. And we do it, unless bfqq is in + * interactive weight raising. We do not do it in the + * latter subcase, for the following reason. bfqq may + * be conveying the I/O needed to load a soft + * real-time application. Such an application will + * actually exhibit a soft real-time I/O pattern after + * it finally starts doing its job. But, if + * soft_rt_next_start is computed here for an + * interactive bfqq, and bfqq had received a lot of + * service before remaining with no outstanding + * request (likely to happen on a fast device), then + * soft_rt_next_start would be assigned such a high + * value that, for a very long time, bfqq would be + * prevented from being possibly considered as soft + * real time. + * + * If, instead, the queue still has outstanding + * requests, then we have to wait for the completion + * of all the outstanding requests to discover whether + * the request pattern is actually isochronous. */ - if (bfqq->dispatched == 0) + if (bfqq->dispatched == 0 && + bfqq->wr_coeff != bfqd->bfq_wr_coeff) bfqq->soft_rt_next_start = bfq_bfqq_softrt_next_start(bfqd, bfqq); - else { + else if (bfqq->dispatched > 0) { /* * Schedule an update of soft_rt_next_start to when * the task may be discovered to be isochronous. @@ -4834,11 +4850,14 @@ static void bfq_completed_request(struct bfq_queue *bfqq, struct bfq_data *bfqd) * isochronous, and both requisites for this condition to hold * are now satisfied, then compute soft_rt_next_start (see the * comments on the function bfq_bfqq_softrt_next_start()). We - * schedule this delayed check when bfqq expires, if it still - * has in-flight requests. + * do not compute soft_rt_next_start if bfqq is in interactive + * weight raising (see the comments in bfq_bfqq_expire() for + * an explanation). We schedule this delayed update when bfqq + * expires, if it still has in-flight requests. */ if (bfq_bfqq_softrt_update(bfqq) && bfqq->dispatched == 0 && - RB_EMPTY_ROOT(&bfqq->sort_list)) + RB_EMPTY_ROOT(&bfqq->sort_list) && + bfqq->wr_coeff != bfqd->bfq_wr_coeff) bfqq->soft_rt_next_start = bfq_bfqq_softrt_next_start(bfqd, bfqq);