From patchwork Wed Dec 20 16:27:36 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 122484 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp5796228qgn; Wed, 20 Dec 2017 08:28:10 -0800 (PST) X-Google-Smtp-Source: ACJfBosrrYHv8UrEzckcfZ/vXsQA9yCgHsWX9LojOqIKVjKYhzNuJ5VSF7iU6ZGvl6Fd5WxRmjEb X-Received: by 10.159.247.134 with SMTP id e6mr7292967pls.279.1513787290232; Wed, 20 Dec 2017 08:28:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513787290; cv=none; d=google.com; s=arc-20160816; b=fZWlHG8UPCnhtjAMDgkmHnUzZQMzeovL/PpHB5frIdf+dW6iBtKpmO3BYegC+CKr2X wo2XUga7yMrUbje/r7E+lVOGTIbp4sh7BwDfUGbkL0Yt7RATyY+rQTfF58XmsuSTLJFL /oCVIC+wNMv/4QKt8/5f3uWaQd3XkNSBA97DBbP4FFdfpcZbRxr8YYavCqKmeHB0ilhV b3Cv8yyHTC3/HehqBoqdIwecL0bKiSsOCdEwmIDCllzVFrWS2dsD40PGuM/V5piKa46q YnlMcnGORQ7x/25BI5Yv7bqV0qzSEzYA8Zc51dWwuAy/qbjgAVBy6Zcvw5Hrk4fe5GVx KNUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=/8sEbIKenUlm0wwUazrCsKpCa9aYPez7m27KHUFJPfk=; b=m4ZY026xFnoNU93njUIBU4znlX7+I6M2E1Vw6/5ouYrrpVokYtWPCSo2R6eRZiclj3 5oLP1YHCpRj5n0q+3FgO1OqWFaEAQFGa3rNwxy9dAotjdi+yB3eUubYWzFLHlhNvrWPs 9Ma2BpgBV+XBJYYtG71wmngKmsKOOphiHjAjzjGBw9r4KK6CHhiM1zk2F7MO4fo5OS26 7WMEifJAaZGlB0fVczkwRfDztIMFnhHKKouxgwMGHWBTDTprUpOEjw5JWSy99uaX3ncO kpU+v9Elv1KMW7N0zXuEWnc87TC1QYU/DLd0l0V3uYSV5e5R29zxDezOgEPRdf+sKUb2 i+Cg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=A1eDiJXw; 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 q24si13457636pfi.54.2017.12.20.08.28.09; Wed, 20 Dec 2017 08:28:10 -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=A1eDiJXw; 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 S1755590AbdLTQ2F (ORCPT + 28 others); Wed, 20 Dec 2017 11:28:05 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:46330 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754428AbdLTQ2B (ORCPT ); Wed, 20 Dec 2017 11:28:01 -0500 Received: by mail-wm0-f68.google.com with SMTP id r78so11034076wme.5 for ; Wed, 20 Dec 2017 08:28:01 -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; bh=/8sEbIKenUlm0wwUazrCsKpCa9aYPez7m27KHUFJPfk=; b=A1eDiJXwaD4k29OqdDgkqchnB8olTPz77+7cgzCO56Z1YbAEFIJ0Ro+KfiIkDHor9f ikqAzNmEMaymRfQmz2Pmit/vaWFwzpyAqUyDb9+NU+9Y3MPmGygrlJNa4t9EsKvx4PEJ oyXTi8feKuXmpBK9qfwqjje4caRYCPE5r0YZk= 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; bh=/8sEbIKenUlm0wwUazrCsKpCa9aYPez7m27KHUFJPfk=; b=ulRRx+R22xnglH6+ULxgqp/WJB1wg2Krs75zq7WHAMJ7Bv7TWBxvQlIC8cjWw/sh4f 3kT3hZnFQN5vTyqgOPhIXlt03z4hlmD/ZsWdgbY/z5dfHRar7bdDKJTbxTw7mqS/uOkt qYakQT3wnLNfOHEbHT/mtYpMYje60ZLT0/UB/jUrrERKYjRUTHlMtZa8TcB9wpmxJ2xy hyZGhwWfopiInlO+JIwCHjbMOUOJtR0V2RRkQpZ0OE8Y5GvTRPyP1mev2CyqUWMucI4G j9DMt4BR24oinHE/QvTX8RBETzpC/rSJXN2uoCoBld64b9xh7atyJXBBnOlGqZWsLR8q JQ2w== X-Gm-Message-State: AKGB3mImcx+2S4++np5uq2kCKka1YyJSZEPWUaqAGH/7MwPyIIhxOGyV SVjFt3RiDmN448cgiVuKgv1V8UCcXY8= X-Received: by 10.28.13.77 with SMTP id 74mr7501806wmn.51.1513787280214; Wed, 20 Dec 2017 08:28:00 -0800 (PST) Received: from localhost.localdomain (labtegrax1.mat.unimo.it. [155.185.5.2]) by smtp.gmail.com with ESMTPSA id k25sm10263636wrk.11.2017.12.20.08.27.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 08:27:59 -0800 (PST) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, broonie@kernel.org, linus.walleij@linaro.org, angeloruocco90@gmail.com, bfq-iosched@googlegroups.com, Paolo Valente Subject: [PATCH IMPROVEMENT] block, bfq: increase threshold to deem I/O as random Date: Wed, 20 Dec 2017 17:27:36 +0100 Message-Id: <20171220162736.5067-1-paolo.valente@linaro.org> X-Mailer: git-send-email 2.15.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If two processes do I/O close to each other, i.e., are cooperating processes in BFQ (and CFQ'S) nomenclature, then BFQ merges their associated bfq_queues, so as to get sequential I/O from the union of the I/O requests of the processes, and thus reach a higher throughput. A merged queue is then split if its I/O stops being sequential. In this respect, BFQ deems the I/O of a bfq_queue as (mostly) sequential only if less than 4 I/O requests are random, out of the last 32 requests inserted into the queue. Unfortunately, extensive testing (with the interleaved_io benchmark of the S suite [1], and with real applications spawning cooperating processes) has clearly shown that, with such a low threshold, only a rather low I/O throughput may be reached when several cooperating processes do I/O. In particular, the outcome of each test run was bimodal: if queue merging occurred and was stable during the test, then the throughput was close to the peak rate of the storage device, otherwise the throughput was arbitrarily low (usually around 1/10 of the peak rate with a rotational device). The probability to get the unlucky outcomes grew with the number of cooperating processes: it was already significant with 5 processes, and close to one with 7 or more processes. The cause of the low throughput in the unlucky runs was that the merged queues containing the I/O of these cooperating processes were soon split, because they contained more random I/O requests than those tolerated by the 4/32 threshold, but - that I/O would have however allowed the storage device to reach peak throughput or almost peak throughput; - in contrast, the I/O of these processes, if served individually (from separate queues) yielded a rather low throughput. So we repeated our tests with increasing values of the threshold, until we found the minimum value (19) for which we obtained maximum throughput, reliably, with at least up to 9 cooperating processes. Then we checked that the use of that higher threshold value did not cause any regression for any other benchmark in the suite [1]. This commit raises the threshold to such a higher value. [1] https://github.com/Algodev-github/S Signed-off-by: Angelo Ruocco Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.15.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index c66578592c9e..e33c5c4c9856 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -192,7 +192,7 @@ static struct kmem_cache *bfq_pool; #define BFQQ_SEEK_THR (sector_t)(8 * 100) #define BFQQ_SECT_THR_NONROT (sector_t)(2 * 32) #define BFQQ_CLOSE_THR (sector_t)(8 * 1024) -#define BFQQ_SEEKY(bfqq) (hweight32(bfqq->seek_history) > 32/8) +#define BFQQ_SEEKY(bfqq) (hweight32(bfqq->seek_history) > 19) /* Min number of samples required to perform peak-rate update */ #define BFQ_RATE_MIN_SAMPLES 32