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: 9677759 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 AA84860382 for ; Wed, 12 Apr 2017 16:24:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9D91F205FB for ; Wed, 12 Apr 2017 16:24:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 923CC28553; Wed, 12 Apr 2017 16:24:15 +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 1D043205FB for ; Wed, 12 Apr 2017 16:24:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754646AbdDLQYN (ORCPT ); Wed, 12 Apr 2017 12:24:13 -0400 Received: from mail-wr0-f178.google.com ([209.85.128.178]:34297 "EHLO mail-wr0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754761AbdDLQYE (ORCPT ); Wed, 12 Apr 2017 12:24:04 -0400 Received: by mail-wr0-f178.google.com with SMTP id z109so20876201wrb.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=JxxhqEPeEAHrBfvS7T4o1R0WKMUY8lhuCMH/WGSMZNYZ8KRcHmKtzQ2B6h+IRLmsTu nTJYLRJ41jaZ1/sk4Vysj6QvMGO2EvwpFiZiF9dcr61ySwj2B8wetG485yIUR+Kd6lhZ hABOKzG/YtwccOvv1yRW7SIlJhtiaS9KZJF09swwHMerPGKLIIhw+Vz1KE9Q1qjMLA3O g5CKqIrZbupHxG1DM3q/Ib8TNaNpXizW/W3Qcmg+eq4fDhVj4L+SBQR2goGav/C26skR jRw+O1JP8IiC4NlvDEcmidVN4XuZ2/GiCrDijiTbd++is3Kmin7LF5Li7CohGc+SQsho oP4g== X-Gm-Message-State: AN3rC/5KvQbkrcPvhqARiDPG1EI528BTGd9icgQrTnO6dmMvvKzr5brChbk4bzyGn7UoKVWW 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-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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(-) 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 &&