From patchwork Sat Mar 4 16:01:25 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 9604055 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 3A0BD60453 for ; Sat, 4 Mar 2017 16:02:50 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2BDCF283CB for ; Sat, 4 Mar 2017 16:02:50 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1F15C2849C; Sat, 4 Mar 2017 16:02:50 +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=-6.5 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM 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 8044D283CB for ; Sat, 4 Mar 2017 16:02:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752547AbdCDQCr (ORCPT ); Sat, 4 Mar 2017 11:02:47 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:34765 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752594AbdCDQCl (ORCPT ); Sat, 4 Mar 2017 11:02:41 -0500 Received: by mail-wm0-f46.google.com with SMTP id 196so12365906wmm.1 for ; Sat, 04 Mar 2017 08:02:35 -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:in-reply-to:references; bh=lgZXcwg1WyaweOUnLPsVCuPV3hu7ViXbHgBKxkicgZI=; b=Cqzps1/16PNTm9b/r+YZbA+Jop6UPIZ7kElYfK+OKWnv8kVLzHkFOnrYoEItlToA6C oMwMN/8inrJh9PqsNOpTZCVrDXPrsL9tRtUGlJvXPxIpIkLqom8aODtL9JQzwh49UBLy 5s7qeZh5f8vcWsILYZpnq8+K4d9fxQYmP5wwA= 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=lgZXcwg1WyaweOUnLPsVCuPV3hu7ViXbHgBKxkicgZI=; b=TZhodQV6DuIon80AtCVd5k6bPxM3O63syURumYGozAAMISinhnjvh1qERN/Blb3TLL P/DeWRGuXd8dVU27ilphMEINCFFl9rN2wGFD1k+E916DxwcW3phEllUR5orukyiR71eu IZzwlV33aXQpPR1CknIRbZcGqpexy/f4GRBfWcrLVfemPHtQquyjjhuDrKxuYsV29cqO sdOpzcqJI77j5lJjavP+zoYMM6RQldORZhdWQeqdyHBLVWq1Ph2J65BF7aAFOD+sbmEc uW6eVMvsgjE8GAR0x6lMoK/NHdYZfirubnuZ9yXSWqQTDPH5wB6iDcPhcIz/lzC3Mg6F rc8g== X-Gm-Message-State: AMke39kP1FLA12JRpA7kAbjM5zQbbfyZejBOMmOp7Hun7W8yD1zcNDGAv4wthbMHi9ZrtVXP X-Received: by 10.28.97.194 with SMTP id v185mr6908048wmb.117.1488643349793; Sat, 04 Mar 2017 08:02:29 -0800 (PST) Received: from localhost.localdomain ([185.14.10.61]) by smtp.gmail.com with ESMTPSA id g6sm7474035wmc.30.2017.03.04.08.02.27 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 04 Mar 2017 08:02:28 -0800 (PST) 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 RFC 08/14] block, bfq: preserve a low latency also with NCQ-capable drives Date: Sat, 4 Mar 2017 17:01:25 +0100 Message-Id: <20170304160131.57366-9-paolo.valente@linaro.org> X-Mailer: git-send-email 2.10.0 In-Reply-To: <20170304160131.57366-1-paolo.valente@linaro.org> References: <20170304160131.57366-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 bc47591..b439779 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -6180,7 +6180,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 &&