From patchwork Thu May 31 14:45:08 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 137418 Delivered-To: patch@linaro.org Received: by 2002:a2e:9706:0:0:0:0:0 with SMTP id r6-v6csp6691586lji; Thu, 31 May 2018 07:45:50 -0700 (PDT) X-Google-Smtp-Source: ADUXVKL2pVJ87dT6gyC0onyG1EHykjm9zD1LRY5XKV/jgDcvI6KtWLLxQqxxRAgbBbozEqElBhDe X-Received: by 2002:a17:902:206:: with SMTP id 6-v6mr7199728plc.294.1527777950762; Thu, 31 May 2018 07:45:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527777950; cv=none; d=google.com; s=arc-20160816; b=Ty1OnF+mnYQNFw6VlUR+AmxswRgUS467ZEEhIFpY9nKbGgtbIF+LUL48AOma3KdgS2 Vqrpild5LDJ1KrVnUv1AsA5NpiHQsV7KsStLvAVLCYg2visPua3fe0g29SYoBGFGFx0/ LCTXVZ1Ke01k86EpqHDZbpDYdbNRPdsmP8cB5BI3PU9ZHPrqrd8+KRi0VVE7czyiNVHu 13uCzWenHFTCiJXT5oD6t2Zk/AUd+NkaT6cUQPHxEFL/MSGIWmLz6qubEEsAyVzFqF2u Q7vkSL7mJrkIAQ3wtXyUzyPyWFVlqzmtRbrazH+jpe06gTeqcKmRvMfCzD+PmTzG333b xeoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=/0Hf7SCJj6Y7ejeDOkPs34vFaFRY+69k50LwZc5XXqI=; b=ZRvdOD/cHtmaePlhABVQHaJ1wAZvthSVe6gg+g3tUKm3qvbAoD7ieVGtqBlgI85BfU vm2rwA0iLhhyItbEPl0iI5kpPc+o47w5SG7Pnr07JmVzW41vUJeE8f5my7KdHJARs+4m wNHWPgOQWk5s06RLDUlqN5Gw2Kh560udcBEll3Mc2FpPnyZaO9TlEtKjfT/nC4+85D7T OTw8HQP4d8/+mwcFyZCrR/9f8KxEbFSeG//RjZJSCK7YUYJNaVvr74jn29EapLYGzIfc 7IiITrQFf32PSRfSv9kXEoIMp/1eJrnDt3eE+DWUn441R5a2PzFOwNZkTm+B/PJR4NHY hkqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hOZ+FKI/; 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 u6-v6si9670914pgb.226.2018.05.31.07.45.50; Thu, 31 May 2018 07:45:50 -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=hOZ+FKI/; 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 S1755476AbeEaOpr (ORCPT + 30 others); Thu, 31 May 2018 10:45:47 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:56148 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755438AbeEaOpe (ORCPT ); Thu, 31 May 2018 10:45:34 -0400 Received: by mail-wm0-f66.google.com with SMTP id a8-v6so54466197wmg.5 for ; Thu, 31 May 2018 07:45:33 -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=/0Hf7SCJj6Y7ejeDOkPs34vFaFRY+69k50LwZc5XXqI=; b=hOZ+FKI/1edNxA6XLKxJHDCcgDilTJKv/OvhypdNUmRPGexLtBqVdEZajrW70jaIQn Tx72g0l1XvmsARF8mXaaEqJKmT8fz/LfXDbEx1/ncvQjFXjuq7GQjhF19WWHvi2i5+JI KGW+gRaHx2o952O8/7JnndJ0ew29p5hfjH4Ws= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=/0Hf7SCJj6Y7ejeDOkPs34vFaFRY+69k50LwZc5XXqI=; b=YjrIwRzD4TwMnPSzMbes9mutIQGo2QIYtqyYqZKreVnBcVqo2MOnvZ3hq0NeeDCBNZ rwa09MOh9W+on/1YHA63QIZhp1yT8QYt2f9sC32/sd4poqNErM2jb5WJzbg8Wzd1hxAG HY8If+tthsQsKgJARnGhiJqTnk+XC/2y2i54O7ygPJmX0D8kScU3UZVs5oLZyKZtMjWR pD2saLlfHtytN4FTyF9NEYM16fbpdLMOMYo+Ha06uBR7o5OENBw5KMwdJzkqzH9GBmaw S0nou4F65QfgE11u2e1Odl17+TW71yQAlRRU4DMpd4QD9672xkO1xcBGI+pRp+2ToehD RHPA== X-Gm-Message-State: ALKqPwfqsgxtlFB+5HMUYdL7X5ceoP/2v3k48W9EBEgGgQVq18On11j1 tIQK3tOzELAcR9hbo4MmTIRkrg== X-Received: by 2002:a1c:6a1a:: with SMTP id f26-v6mr179479wmc.1.1527777933040; Thu, 31 May 2018 07:45:33 -0700 (PDT) Received: from localhost.localdomain (146-241-12-84.dyn.eolo.it. [146.241.12.84]) by smtp.gmail.com with ESMTPSA id y45-v6sm36106869wrd.97.2018.05.31.07.45.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 07:45:32 -0700 (PDT) From: Paolo Valente To: Jens Axboe Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, ulf.hansson@linaro.org, broonie@kernel.org, linus.walleij@linaro.org, bfq-iosched@googlegroups.com, oleksandr@natalenko.name, sapienza.dav@gmail.com, 177992@studenti.unimore.it, Paolo Valente Subject: [PATCH BUGFIX/IMPROVEMENTS 4/4] block, bfq: prevent soft_rt_next_start from being stuck at infinity Date: Thu, 31 May 2018 16:45:08 +0200 Message-Id: <20180531144508.3927-5-paolo.valente@linaro.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180531144508.3927-1-paolo.valente@linaro.org> References: <20180531144508.3927-1-paolo.valente@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Davide Sapienza BFQ can deem a bfq_queue as soft real-time only if the queue - periodically becomes completely idle, i.e., empty and with no still-outstanding I/O request; - after becoming idle, gets new I/O only after a special reference time soft_rt_next_start. In this respect, after commit "block, bfq: consider also past I/O in soft real-time detection", the value of soft_rt_next_start can never decrease. This causes a problem with the following special updating case for soft_rt_next_start: to prevent queues that are not completely idle to be wrongly detected as soft real-time (when they become non-empty again), soft_rt_next_start is temporarily set to infinity for empty queues with still outstanding I/O requests. But, if such an update is actually performed, then, because of the above commit, soft_rt_next_start will be stuck at infinity forever, and the queue will have no more chance to be considered soft real-time. On slow systems, this problem does cause actual soft real-time applications to be occasionally not detected as such. This commit addresses this issue by eliminating the pushing of soft_rt_next_start to infinity, and by changing the way non-empty queues are prevented from being wrongly detected as soft real-time. Simply, a queue that becomes non-empty again can now be detected as soft real-time only if it has no outstanding I/O request. Signed-off-by: Davide Sapienza Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 29 ++--------------------------- 1 file changed, 2 insertions(+), 27 deletions(-) -- 2.16.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 31ce089d54eb..37cadc643c56 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -1416,15 +1416,6 @@ static bool bfq_bfqq_update_budg_for_activation(struct bfq_data *bfqd, return wr_or_deserves_wr; } -/* - * Return the farthest future time instant according to jiffies - * macros. - */ -static unsigned long bfq_greatest_from_now(void) -{ - return jiffies + MAX_JIFFY_OFFSET; -} - /* * Return the farthest past time instant according to jiffies * macros. @@ -1569,7 +1560,8 @@ static void bfq_bfqq_handle_idle_busy_switch(struct bfq_data *bfqd, in_burst = bfq_bfqq_in_large_burst(bfqq); soft_rt = bfqd->bfq_wr_max_softrt_rate > 0 && !in_burst && - time_is_before_jiffies(bfqq->soft_rt_next_start); + time_is_before_jiffies(bfqq->soft_rt_next_start) && + bfqq->dispatched == 0; *interactive = !in_burst && idle_for_long_time; wr_or_deserves_wr = bfqd->low_latency && (bfqq->wr_coeff > 1 || @@ -3272,23 +3264,6 @@ void bfq_bfqq_expire(struct bfq_data *bfqd, bfqq->soft_rt_next_start = bfq_bfqq_softrt_next_start(bfqd, bfqq); else { - /* - * The application is still waiting for the - * completion of one or more requests: - * prevent it from possibly being incorrectly - * deemed as soft real-time by setting its - * soft_rt_next_start to infinity. In fact, - * without this assignment, the application - * would be incorrectly deemed as soft - * real-time if: - * 1) it issued a new request before the - * completion of all its in-flight - * requests, and - * 2) at that time, its soft_rt_next_start - * happened to be in the past. - */ - bfqq->soft_rt_next_start = - bfq_greatest_from_now(); /* * Schedule an update of soft_rt_next_start to when * the task may be discovered to be isochronous.