From patchwork Mon Jul 15 09:31:53 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 168986 Delivered-To: patch@linaro.org Received: by 2002:a92:4782:0:0:0:0:0 with SMTP id e2csp4149690ilk; Mon, 15 Jul 2019 02:32:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqzoj0iUqlsz59r4FNG9XbV63MHOacDwRvwNR6SHWDMrn51u15b4hh7Nht6vubS3/kydGyWZ X-Received: by 2002:a17:902:a413:: with SMTP id p19mr27478366plq.134.1563183135945; Mon, 15 Jul 2019 02:32:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563183135; cv=none; d=google.com; s=arc-20160816; b=g6g3y5jFQ7obCPJ8szaN5OMNu/rUaG6njy2kPG8tOMALlfZ0zoAjbeU4YB+KcEX9Wu g/BMX6YHcS+tRXclmZ+otMfObxkQVo+422fhyv/S34XRqgzVKOzNxbOk++Z73/NBoNrd VFQxd7I4nDAl5/yNgSYMGrb61UbvhszVts1GS35XWvjBn4g5uxJ7glRE3bOaeCAnliP0 vN9F0uh6rWxKJJCpczTSMGOnRt8UKc+LfScIaF41vlti95IU0W2mXKNTf8jaciaBJCbB vej5eW3vNebDLzrKRsbYg+6MQr3h4DnxW8h58CBr2Dux2QKaimpJDf5PuJhcBN+2iCqa w0xg== 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=XY6uMFDpyd5Sb/D44V2DuZasBvPQUw/5AeqlUOCrBVk=; b=ZLQYSfBxoa5CjB+wmJkWK3wpaJi7SC+y6iVPLMd+ln46F063qkQ9OlE4u9W0uU7dNh yEUnJrpy6Q8+bDefgpSFUQs2TjVrvDIoPHikwfpSj6MV0bZpc/UQL/hgcdFJ57YMm/f/ yBLCOJ/47/WFqY3H2A7peNtEHHHVt9IfW/l1AjCisPUJbiniykeTyiDKCjfzue3vk+5m +YO5cREt4MH4RRUdQ2MoWk4Pv/9POHQ+ZHtLrmt4i9y1CfNRgA+FVMt/DhMKK9xAmee4 isn8LTX77pyHkZ1POuWU3X+IAo4IVeM2YLA/vhe1y0ggtYHj1QC0du2olh8zd62mzqrF AEIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=BxEJpF4E; 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 z26si16742367pfj.247.2019.07.15.02.32.15; Mon, 15 Jul 2019 02:32:15 -0700 (PDT) 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=BxEJpF4E; 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 S1729559AbfGOJcO (ORCPT + 29 others); Mon, 15 Jul 2019 05:32:14 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:43160 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729428AbfGOJcK (ORCPT ); Mon, 15 Jul 2019 05:32:10 -0400 Received: by mail-wr1-f66.google.com with SMTP id p13so16253574wru.10 for ; Mon, 15 Jul 2019 02:32:09 -0700 (PDT) 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=XY6uMFDpyd5Sb/D44V2DuZasBvPQUw/5AeqlUOCrBVk=; b=BxEJpF4ENRRLiT4Njdp0BlI+017tozpowFfpa0ojf6zePDxsoUAmlG1yg0ix1KSbT5 36fmmf+wxNPtw6BsyQRRk3XhrveCG5LMtqwr4Vc5puRj1AXcLo/+RQKz6JgKv+p2V/vY frgYSPbE58HzEwZyFr6M1HoPyLzDwEhTL+o5OfD5QeKJg6GizNZGS1AldpNP7P2gQwPI tf1CHG//qT7/5QAhpNEFcbr9tp0el8Q4LtMu3lHzo0x6vPD8um7CpydssJtw4tB1g+iK +dYSrAd8ACPHmZF+6Of299tsyIFFis3xaXjQrBwWm1yZ8QWn5Nt38rcntWIEpVJIhnTU c2xA== 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=XY6uMFDpyd5Sb/D44V2DuZasBvPQUw/5AeqlUOCrBVk=; b=IGI5M03Tk+tH13OKu6XJxHtDfNN+x1NsijpbAW2qH8eosjZ7yIEFQgoHNcIFY0eLGJ sSAd4O+s9GllIJ4NbpDoE3RrcoI33lgPB+KZWB+8ioxeGTNYp7zQTa38QWParQfKKmyA Uda1y+wwVPuHyKx5wgePkDlpPU6mUQGY2gqnvxl4ZfOO8YW9PDSrdJJJy74///GmasU4 EjrSnLYTRT6lXXZJUlGDNR92PnWMLea2jxV8D3B1bLXBgxxfVU6YjsqBSvr461lgTPCI Skll4VN2PyYV3QNhtMTmpLSXb73hMzXyc+1ichs57pFAenIejwacppPGUj8skF59Ip/q Locg== X-Gm-Message-State: APjAAAUlIb7NiBoBlehsBw5qyZhIsgxKXmfjsmbjYLA5ADmD2+1sLkV5 YvxQ3E1TtJYo3qBlmHhIAA5WKg== X-Received: by 2002:a5d:5348:: with SMTP id t8mr27162017wrv.159.1563183128309; Mon, 15 Jul 2019 02:32:08 -0700 (PDT) Received: from localhost.localdomain (146-241-97-230.dyn.eolo.it. [146.241.97.230]) by smtp.gmail.com with ESMTPSA id g12sm22544993wrv.9.2019.07.15.02.32.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 02:32:07 -0700 (PDT) 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, bfq-iosched@googlegroups.com, oleksandr@natalenko.name, Paolo Valente Subject: [PATCH BUGFIX IMPROVEMENT 1/1] block, bfq: check also in-flight I/O in dispatch plugging Date: Mon, 15 Jul 2019 11:31:53 +0200 Message-Id: <20190715093153.19821-2-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190715093153.19821-1-paolo.valente@linaro.org> References: <20190715093153.19821-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 Consider a sync bfq_queue Q that remains empty while in service, and suppose that, when this happens, there is a fair amount of already in-flight I/O not belonging to Q. This situation is not considered when deciding whether to plug I/O dispatching (until new I/O arrives for Q). But it has to be checked, for the following reason. The drive may decide to serve in-flight non-Q's I/O requests before Q's ones, thereby delaying the arrival of new I/O requests for Q (recall that Q is sync). If I/O-dispatching is not plugged, then, while Q remains empty, a basically uncontrolled amount of I/O from other queues may be dispatched too, possibly causing the service of Q's I/O to be delayed even longer in the drive. This problem gets more and more serious as the speed and the queue depth of the drive grow, because, as these two quantities grow, the probability to find no queue busy but many requests in flight grows too. This commit performs I/O-dispatch plugging in this scenario. Plugging minimizes the delay induced by already in-flight I/O, and enables Q to recover the bandwidth it may lose because of this delay. As a practical example, under write load on a Samsung SSD 970 PRO, gnome-terminal starts in 1.5 seconds after this fix, against 15 seconds before the fix (as a reference, gnome-terminal takes about 35 seconds to start with any of the other I/O schedulers). Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 67 +++++++++++++++++++++++++++++---------------- 1 file changed, 43 insertions(+), 24 deletions(-) -- 2.20.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index ddf042b36549..c719020fa121 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -3744,38 +3744,57 @@ static void bfq_dispatch_remove(struct request_queue *q, struct request *rq) * there is no active group, then the primary expectation for * this device is probably a high throughput. * - * We are now left only with explaining the additional - * compound condition that is checked below for deciding - * whether the scenario is asymmetric. To explain this - * compound condition, we need to add that the function + * We are now left only with explaining the two sub-conditions in the + * additional compound condition that is checked below for deciding + * whether the scenario is asymmetric. To explain the first + * sub-condition, we need to add that the function * bfq_asymmetric_scenario checks the weights of only - * non-weight-raised queues, for efficiency reasons (see - * comments on bfq_weights_tree_add()). Then the fact that - * bfqq is weight-raised is checked explicitly here. More - * precisely, the compound condition below takes into account - * also the fact that, even if bfqq is being weight-raised, - * the scenario is still symmetric if all queues with requests - * waiting for completion happen to be - * weight-raised. Actually, we should be even more precise - * here, and differentiate between interactive weight raising - * and soft real-time weight raising. + * non-weight-raised queues, for efficiency reasons (see comments on + * bfq_weights_tree_add()). Then the fact that bfqq is weight-raised + * is checked explicitly here. More precisely, the compound condition + * below takes into account also the fact that, even if bfqq is being + * weight-raised, the scenario is still symmetric if all queues with + * requests waiting for completion happen to be + * weight-raised. Actually, we should be even more precise here, and + * differentiate between interactive weight raising and soft real-time + * weight raising. + * + * The second sub-condition checked in the compound condition is + * whether there is a fair amount of already in-flight I/O not + * belonging to bfqq. If so, I/O dispatching is to be plugged, for the + * following reason. The drive may decide to serve in-flight + * non-bfqq's I/O requests before bfqq's ones, thereby delaying the + * arrival of new I/O requests for bfqq (recall that bfqq is sync). If + * I/O-dispatching is not plugged, then, while bfqq remains empty, a + * basically uncontrolled amount of I/O from other queues may be + * dispatched too, possibly causing the service of bfqq's I/O to be + * delayed even longer in the drive. This problem gets more and more + * serious as the speed and the queue depth of the drive grow, + * because, as these two quantities grow, the probability to find no + * queue busy but many requests in flight grows too. By contrast, + * plugging I/O dispatching minimizes the delay induced by already + * in-flight I/O, and enables bfqq to recover the bandwidth it may + * lose because of this delay. * * As a side note, it is worth considering that the above - * device-idling countermeasures may however fail in the - * following unlucky scenario: if idling is (correctly) - * disabled in a time period during which all symmetry - * sub-conditions hold, and hence the device is allowed to - * enqueue many requests, but at some later point in time some - * sub-condition stops to hold, then it may become impossible - * to let requests be served in the desired order until all - * the requests already queued in the device have been served. + * device-idling countermeasures may however fail in the following + * unlucky scenario: if I/O-dispatch plugging is (correctly) disabled + * in a time period during which all symmetry sub-conditions hold, and + * therefore the device is allowed to enqueue many requests, but at + * some later point in time some sub-condition stops to hold, then it + * may become impossible to make requests be served in the desired + * order until all the requests already queued in the device have been + * served. The last sub-condition commented above somewhat mitigates + * this problem for weight-raised queues. */ static bool idling_needed_for_service_guarantees(struct bfq_data *bfqd, struct bfq_queue *bfqq) { bool asymmetric_scenario = (bfqq->wr_coeff > 1 && - bfqd->wr_busy_queues < - bfq_tot_busy_queues(bfqd)) || + (bfqd->wr_busy_queues < + bfq_tot_busy_queues(bfqd) || + bfqd->rq_in_driver >= + bfqq->dispatched + 4)) || bfq_asymmetric_scenario(bfqd, bfqq); bfq_log_bfqq(bfqd, bfqq,