From patchwork Sun Mar 10 18:11:29 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 160026 Delivered-To: patch@linaro.org Received: by 2002:a02:5cc1:0:0:0:0:0 with SMTP id w62csp11089884jad; Sun, 10 Mar 2019 11:12:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqyz7FGwjJVmUjlePc2ZxE4LCm2hshMA755lh/cyWz7fHjQJUb5heh3GT3Rhb+5CYsq0L8d0 X-Received: by 2002:a17:902:9a98:: with SMTP id w24mr29326624plp.247.1552241534641; Sun, 10 Mar 2019 11:12:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552241534; cv=none; d=google.com; s=arc-20160816; b=hkQJyhQhnUY99fjlzGuykKYxODkCbjwftLE8t3GCU1cpVoVKqG4VWhuG5vf50h28UJ xeyz7EI4i2ItgGtNyLcrqjSIcsyWR6SibXIBP+Vi7eF5Ec6z58gH4Fr0aLiVhtKgbkOq WYZJ15pLo1o6gH8vHwZ8v1NAfG/mRhuhBCpdHhdj8+rgnR0KZxPtL7sZ6Flu+JfWm6l/ L2b2ErwN2yDF6rF5L8TpWtcIKZhenagq/HRWu4fwzvClvvo+xEPD1qWxF6GHH1XzQ/DX 8eddxaael75RsFzlXVV866RHyTxvwBZa/CsV2dPQn5lb20C4VUemqU4FPq/Y6r49ZoLn Y2fQ== 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=SY00KoFWeTwZXwxCAxRn3goBCIvGzbExPxId3YVmDAI=; b=bkQiMI79P78QOMhuTHl41mUlqc3EEr/hZjSL8JnC6QSFuhscgzM9emCLETZffy3kkw A9pedt3s10qTLlDLp0L7txwgy7MRTMSm9i15lEzPW1ls5XbWqG0tj4rPArjAdpv2drzE 4BC/N8rYnXZzcR+N7+Bl5ea+exnAbY5YWopl4y+p8oj9lz04SLmq9l32pxuzj369lf1e 9e4ZWaFvLsbYQIZ/zTWcfAj8m67rfXJFHA1nEUPsN0qu2E6mzaU2t/uuEkt6MwKhj7tX ztxnt/V4kNiLiZHmIR1Lgus119S6y+DxPGt2q28U8ufveMis7moJn69W2VO5QxI7l01s Hoxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="L/K3M0uY"; 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 z23si3129436pgu.132.2019.03.10.11.12.14; Sun, 10 Mar 2019 11:12:14 -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="L/K3M0uY"; 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 S1726881AbfCJSMM (ORCPT + 31 others); Sun, 10 Mar 2019 14:12:12 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:53175 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726865AbfCJSMJ (ORCPT ); Sun, 10 Mar 2019 14:12:09 -0400 Received: by mail-wm1-f65.google.com with SMTP id f65so2213238wma.2 for ; Sun, 10 Mar 2019 11:12:08 -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=SY00KoFWeTwZXwxCAxRn3goBCIvGzbExPxId3YVmDAI=; b=L/K3M0uYUBbqVjojJG+/UOlGrYywm685K9LWp12a8TuqJIqoSV9LLER2Wga7GgCP7I iLpBKDlCtw3K61Com+z0O7IohUEHMADZL7UXzXZBeB1TeJrdg+Tka1GCJtth0+Jfyrkd Xx2hwFjuBCEcpmNp25XaJYpqayHDsPz0uFYJjnYXz+edXJ6OPiRS4jMUxzjnLyzCJf38 qPygtOV/g1r6s4Zb74dgntggVsXMO56V4XgIM9C9UNW3AtvMiA3Sx+yFh4aZ3mXL84a3 +KKFqe8g/6za9sI5EJdlC9fp5WCjhN+1GM9ZU4lA1dXghb5JW4Prwru/RAswNQZMISDB 7Mpg== 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=SY00KoFWeTwZXwxCAxRn3goBCIvGzbExPxId3YVmDAI=; b=YRB1AoYzgySx0y6IHYkMYWQz/EcKoFmrX7lPiARqz0ON9rMLrC/0Zn+YPL0RZwOV5t f0odUvZjlISV+3xyJx9Dza0t4I+JkvWpPcA92PzwKehsWFLY354ovHy7/WvcUt/8awhV mICgeuafXQHm7rAbnLMF2TKDY2p5Xaqds9tVTNjYNmJEo0C5T6qzW3ucriaUBWMspLZO d/cKh52+ZQMZUcxzyFYpICjGjwJm6vtzmZZGZUxq6RUDjd7LE3Mfteb3Hs0lDfl/TsWB 5bz8dACFHRfxdavypPt/cVuqi8mhCVbOLTZKgHpdYW3arR3nyqDTO1FBOV+Jt4R90qOW byWQ== X-Gm-Message-State: APjAAAWkjOoAwhkRodsfaQvD/sF4/aRqZjoLySmJGkPI26sMO6puxp+B 8if5p2Ao/hKJPdLCnnuvT1ek+A== X-Received: by 2002:a7b:c1c1:: with SMTP id a1mr8875305wmj.77.1552241527459; Sun, 10 Mar 2019 11:12:07 -0700 (PDT) Received: from localhost.localdomain (146-241-67-113.dyn.eolo.it. [146.241.67.113]) by smtp.gmail.com with ESMTPSA id d206sm24906368wmc.11.2019.03.10.11.12.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Mar 2019 11:12:06 -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, broonie@kernel.org, bfq-iosched@googlegroups.com, oleksandr@natalenko.name, fra.fra.800@gmail.com, alessio.masola@gmail.com, Paolo Valente Subject: [PATCH BUGFIX IMPROVEMENT V2 1/9] block, bfq: increase idling for weight-raised queues Date: Sun, 10 Mar 2019 19:11:29 +0100 Message-Id: <20190310181137.2604-2-paolo.valente@linaro.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190310181137.2604-1-paolo.valente@linaro.org> References: <20190310181137.2604-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 If a sync bfq_queue has a higher weight than some other queue, and remains temporarily empty while in service, then, to preserve the bandwidth share of the queue, it is necessary to plug I/O dispatching until a new request arrives for the queue. In addition, a timeout needs to be set, to avoid waiting for ever if the process associated with the queue has actually finished its I/O. Even with the above timeout, the device is however not fed with new I/O for a while, if the process has finished its I/O. If this happens often, then throughput drops and latencies grow. For this reason, the timeout is kept rather low: 8 ms is the current default. Unfortunately, such a low value may cause, on the opposite end, a violation of bandwidth guarantees for a process that happens to issue new I/O too late. The higher the system load, the higher the probability that this happens to some process. This is a problem in scenarios where service guarantees matter more than throughput. One important case are weight-raised queues, which need to be granted a very high fraction of the bandwidth. To address this issue, this commit lower-bounds the plugging timeout for weight-raised queues to 20 ms. This simple change provides relevant benefits. For example, on a PLEXTOR PX-256M5S, with which gnome-terminal starts in 0.6 seconds if there is no other I/O in progress, the same applications starts in - 0.8 seconds, instead of 1.2 seconds, if ten files are being read sequentially in parallel - 1 second, instead of 2 seconds, if, in parallel, five files are being read sequentially, and five more files are being written sequentially Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.20.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 4c592496a16a..eb658de3cc40 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -2545,6 +2545,8 @@ static void bfq_arm_slice_timer(struct bfq_data *bfqd) if (BFQQ_SEEKY(bfqq) && bfqq->wr_coeff == 1 && bfq_symmetric_scenario(bfqd)) sl = min_t(u64, sl, BFQ_MIN_TT); + else if (bfqq->wr_coeff > 1) + sl = max_t(u32, sl, 20ULL * NSEC_PER_MSEC); bfqd->last_idling_start = ktime_get(); hrtimer_start(&bfqd->idle_slice_timer, ns_to_ktime(sl),