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: 10125913 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 2DD8C60388 for ; Wed, 20 Dec 2017 16:28:04 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 20F5227F10 for ; Wed, 20 Dec 2017 16:28:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 15A4128D61; Wed, 20 Dec 2017 16:28:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 93FFE27F10 for ; Wed, 20 Dec 2017 16:28:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754516AbdLTQ2C (ORCPT ); Wed, 20 Dec 2017 11:28:02 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:41661 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753452AbdLTQ2B (ORCPT ); Wed, 20 Dec 2017 11:28:01 -0500 Received: by mail-wm0-f66.google.com with SMTP id g75so11070440wme.0 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=sLDAhOvNgChomGXhc43bKwNHieoB6yg3L9WziZg0iqlLa7x2tQUf+asJ+M32DaC4/l KLSOSlXKNqbLbsroIaJACYNehBhCR1AS8C35vwUL/UCCXANVmFVJtbgKS/1wFBB9BqlJ MVff+kXsz1fDkSdG72+E1U8D5wF6PGlxOMUfWxrSRIaauzhrfm2bzqDlR5MpH0t9/sxB rTOitW9rmE8/yoetz5WRFIZfAdF+9H5UgZJjrTwylSdH/3eJEW4qObArLTMrg4/KaT93 bXzZrASCxjJWwfSVyahbNcdbCvJ5ztUs0lOD/tob2nD3M58xP/QCYlLofh5OqLGkOTAS vL0A== X-Gm-Message-State: AKGB3mKJ6lVaEPej9G117XOxmjVvCNRB3uYdiulMV6cOlhVAbOG5azt8 RLOK+h76af7g/HnoBVGZrffQ/A== X-Google-Smtp-Source: ACJfBouZIo3ljAvww53XABEeYaL09y0H2ReWo1qeqFvSxJFOSTDNasxBNbQslVCv7CRe3MdspTmPkg== 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-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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(-) 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