From patchwork Tue Apr 11 13:43:07 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 9675387 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 8F89D60381 for ; Tue, 11 Apr 2017 13:47:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 84C5328569 for ; Tue, 11 Apr 2017 13:47:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 78BA92856B; Tue, 11 Apr 2017 13:47:40 +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 A814C28569 for ; Tue, 11 Apr 2017 13:47:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753490AbdDKNrf (ORCPT ); Tue, 11 Apr 2017 09:47:35 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:34968 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753460AbdDKNoQ (ORCPT ); Tue, 11 Apr 2017 09:44:16 -0400 Received: by mail-wm0-f51.google.com with SMTP id w64so64146232wma.0 for ; Tue, 11 Apr 2017 06:44:15 -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=LDer4b5UzGsHMCASSQ83sPrpMVeImhce6zow89i+hMR1DmLzzm0DhZUjzroTxkbGB2 b0wO56V52AVatMIN43KA4Wi+Xvah/Av9BoXN4zYkINmPlltslZMqFquDydFwfXGIZ481 qRx+rQ8TJTwafXoBJfgNfo2zHxkMY5rtau3Ms= 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=pW3hfDPD25Omkuj7Y5T6v+FLYAwzHi8GjSvKGf6x/NfSzly0UzDOihsGIokKTOiGl+ Ad4E07Y0Vdu4glIdzSLxHfER6lTDD/NiOnvpRxdDmWNJsBdEqL3c7EZoIb1blNPsuOtp xNwLgrPq11XczZ3xx5Pdy43ZeSIbKEd5zW3WPzGJIOWnzuqjUWbsslsswvdk167GrZGe Hh2Zl8hhGW98r0biSwIR+3u21d/8ePVamq5k7ntL6lQm0J+5U58twmrMWSzELz4FJ+Vk q8iKDapI6rKTg+2F/SwI6NRgMAsuMwO5U1qHKWXQ9VMbGi2xhdJ7tfqZZZfORirwyRPA CXOg== X-Gm-Message-State: AN3rC/79Fcd3uierkdQlLGUuxLP06rbXWumy+e/1UcUz5xZO0KSkMX0Bukmjk0RARvyL46No X-Received: by 10.28.54.66 with SMTP id d63mr14159425wma.103.1491918254930; Tue, 11 Apr 2017 06:44:14 -0700 (PDT) Received: from localhost.localdomain ([185.14.8.188]) by smtp.gmail.com with ESMTPSA id v186sm2572933wmv.2.2017.04.11.06.44.13 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 11 Apr 2017 06:44:14 -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 V3 08/16] block, bfq: preserve a low latency also with NCQ-capable drives Date: Tue, 11 Apr 2017 15:43:07 +0200 Message-Id: <20170411134315.44135-9-paolo.valente@linaro.org> X-Mailer: git-send-email 2.10.0 In-Reply-To: <20170411134315.44135-1-paolo.valente@linaro.org> References: <20170411134315.44135-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 &&