From patchwork Wed Apr 12 16:23:14 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 97303 Delivered-To: patch@linaro.org Received: by 10.140.109.52 with SMTP id k49csp345039qgf; Wed, 12 Apr 2017 09:24:30 -0700 (PDT) X-Received: by 10.99.125.12 with SMTP id y12mr19005912pgc.146.1492014270133; Wed, 12 Apr 2017 09:24:30 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u1si20944050pfb.23.2017.04.12.09.24.29; Wed, 12 Apr 2017 09:24:30 -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; 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 S1754849AbdDLQYL (ORCPT + 16 others); Wed, 12 Apr 2017 12:24:11 -0400 Received: from mail-wr0-f176.google.com ([209.85.128.176]:34297 "EHLO mail-wr0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754825AbdDLQYB (ORCPT ); Wed, 12 Apr 2017 12:24:01 -0400 Received: by mail-wr0-f176.google.com with SMTP id z109so20876197wrb.1 for ; Wed, 12 Apr 2017 09:23:59 -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; bh=ljNGCkz/Xo7cGKBDlLJ+6n4zdnZikRW5oe9byLi8+MM=; b=UYYXspIeFVYeke89bybk7ivL+9t8a5LmGCLns6DLYNY6qL6RMnAFHmVxRwcIucqVOx 5i4kECDr2FCI4W9o1hCntOmEjRZWN9r0GrbWpr/GFxA6eTEDWuK/Q6hWepbOSc77eUMG mRzPxixe1P9jxcgUcT+/Of69fda0me9mxcpC8= 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; bh=ljNGCkz/Xo7cGKBDlLJ+6n4zdnZikRW5oe9byLi8+MM=; b=WrvkUH13INM3hBYoz45RjV3J53NxT4uCljESq91JbrditqU/Wp3sSfAaVV0ef3ydSw T9WGWVoPmXsLIeMUc8K97ID4UYjV7U34k13xMFMRwDvzbsDhs1fWvaXYsrlG90dKdCWX X1p5sB/ew9qyp7nH6tOIg4lQ4r7dUTiGnHxwQdaEm9yrCegCF+mLBw5ZUgsLPQY/pyTN MwiXSh9fXxTYuvBwphdt2PodWKQA8nowXO7U0Ls/t0Yx96CPaaEcZAzFd/HteH8XIg+E J+rvcLyOiLLiJP5RLowJ78/wjaAY2GJB/9eHH7lD6o04ebATYHOysrM5j/TlCpJ+cO/k kvvQ== X-Gm-Message-State: AN3rC/43cY2EBDrs3JXNF2zm3lODyJq62MOicUaAwJ5velSgnXTbUtelqJN//K3F1jQO/te2 X-Received: by 10.223.136.131 with SMTP id f3mr3846582wrf.118.1492014238162; Wed, 12 Apr 2017 09:23:58 -0700 (PDT) Received: from localhost.localdomain ([185.14.8.188]) by smtp.gmail.com with ESMTPSA id a10sm26302738wra.17.2017.04.12.09.23.56 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 12 Apr 2017 09:23:57 -0700 (PDT) From: Paolo Valente To: Jens Axboe , Tejun Heo Cc: Fabio Checconi , Arianna Avanzini , linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, linus.walleij@linaro.org, broonie@kernel.org, Paolo Valente Subject: [PATCH V4 08/16] block, bfq: preserve a low latency also with NCQ-capable drives Date: Wed, 12 Apr 2017 18:23:14 +0200 Message-Id: <20170412162322.11139-9-paolo.valente@linaro.org> X-Mailer: git-send-email 2.10.0 In-Reply-To: <20170412162322.11139-1-paolo.valente@linaro.org> References: <20170412162322.11139-1-paolo.valente@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I/O schedulers typically allow NCQ-capable drives to prefetch I/O requests, as NCQ boosts the throughput exactly by prefetching and internally reordering requests. Unfortunately, as discussed in detail and shown experimentally in [1], this may cause fairness and latency guarantees to be violated. The main problem is that the internal scheduler of an NCQ-capable drive may postpone the service of some unlucky (prefetched) requests as long as it deems serving other requests more appropriate to boost the throughput. This patch addresses this issue by not disabling device idling for weight-raised queues, even if the device supports NCQ. This allows BFQ to start serving a new queue, and therefore allows the drive to prefetch new requests, only after the idling timeout expires. At that time, all the outstanding requests of the expired queue have been most certainly served. [1] P. Valente and M. Andreolini, "Improving Application Responsiveness with the BFQ Disk I/O Scheduler", Proceedings of the 5th Annual International Systems and Storage Conference (SYSTOR '12), June 2012. Slightly extended version: http://algogroup.unimore.it/people/paolo/disk_sched/bfq-v1-suite- results.pdf Signed-off-by: Paolo Valente Signed-off-by: Arianna Avanzini --- block/bfq-iosched.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.10.0 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 7f94ad3..574a5f6 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -6233,7 +6233,8 @@ static void bfq_update_idle_window(struct bfq_data *bfqd, if (atomic_read(&bic->icq.ioc->active_ref) == 0 || bfqd->bfq_slice_idle == 0 || - (bfqd->hw_tag && BFQQ_SEEKY(bfqq))) + (bfqd->hw_tag && BFQQ_SEEKY(bfqq) && + bfqq->wr_coeff == 1)) enable_idle = 0; else if (bfq_sample_valid(bfqq->ttime.ttime_samples)) { if (bfqq->ttime.ttime_mean > bfqd->bfq_slice_idle &&