From patchwork Mon Jun 25 19:55:34 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 139887 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp4378173lji; Mon, 25 Jun 2018 12:56:43 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJtK3fTcFUWN+rqONoU8xUbV72D/7WNdvW7V76xWziPkFMfevatXAzElokoY12BgByZcC2t X-Received: by 2002:a65:4a92:: with SMTP id b18-v6mr11622771pgu.107.1529956603639; Mon, 25 Jun 2018 12:56:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529956603; cv=none; d=google.com; s=arc-20160816; b=YUbFRG1KfYh4A3EFgrRRQOIJ6iBLUex95unE3qjkFFAQ4FK9Yi6J3RmiEGc4rYavim 6Gv1O3q9hf88UpHXku+X/h4XD3dpZ3IAWe9WAX2hjkpDk6JBHSHvP6VG5EKlz2kpLDKp uDdjwMAtG6hti0vRHsW7O4w33Q54jQfmkNGmGYzRNy4QHSWSjvtLQ8aLqHpKRYxJUish +ooPVvlrOToGYrghGAh49zUwbmu3phB8P3S7lWPTVkm2M/K+lhgCXcxw9fz51PaYgsa7 AdyrhhgrRmah6CmLXnwkl5IPFG1XiQcx+oegoPZNFF+QPDuHVlUR9DE0+urwFJoaVK/d 42DA== 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=iLVhnU7LLoCaW4lOc7bzsWA0oIfhsKCR8yo/rG/4vtQ=; b=s5GvMt1Qn7iG1+Liw+DeSmrbkfu6l+yW2z+y8hSaViey2OMbdQyU1x+u/0My2voWaA qqslyjPbGRQbEvvuwNLWF+BMsKaLEnkjTo5ukjr5So2aay7Q19jNQxcUYSTc10xR+wZQ i75IEKpRsV8jt0NlrwgsIY8q1QoLunGd0ElNjXbL3wB0mPozPZ/Gmp/94oesztjcsKDh ed+dFqf4YweQT8LYEUxj+NVDCBz/Lxj2rs9fdsmRqRu0EAsTJl3uedJG/HIzyUXfqLHJ w5rxL2fUQ2joB5aJrKGgUpoIqJDQNf0iMSIVAA6aleJ0P1RNX4dvdJD3sVwW8KCpIaiY YkWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=gC0vs0BK; 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 z2-v6si12270258pgc.435.2018.06.25.12.56.43; Mon, 25 Jun 2018 12:56:43 -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=gC0vs0BK; 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 S965152AbeFYT4l (ORCPT + 31 others); Mon, 25 Jun 2018 15:56:41 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:38566 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964980AbeFYTzw (ORCPT ); Mon, 25 Jun 2018 15:55:52 -0400 Received: by mail-wr0-f196.google.com with SMTP id e18-v6so14868055wrs.5 for ; Mon, 25 Jun 2018 12:55:51 -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=iLVhnU7LLoCaW4lOc7bzsWA0oIfhsKCR8yo/rG/4vtQ=; b=gC0vs0BKLnoMLzo+DvIFmlFJJETL4oSycWMGTs4kiDcFHqcBCpXNl4xEbYJpKtDun6 BAEB+CZEIHEgem7Rf6Uld9sUeUcT07GG76EA6rcwutcLihBPztdJxAykEmdVFg3E4rEx M9+yAXC3kgY0s766mTIyeH757wOjjXg7iwjUY= 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=iLVhnU7LLoCaW4lOc7bzsWA0oIfhsKCR8yo/rG/4vtQ=; b=VsX1WwBfz26p1ddDo2J5iy/My+c1dVPs4GqguiBqZWAqi86fZMDKrkmkvNgzRvK5f/ O93I5vLQyL694Wg8AjtLvxD9haCxn4pBIfpfzgKj9gX/kEgr4jJB5b8/wAKDPERh5C3n /01U9W3FajQN3rLPixVO8nzdd3Bp0P9bNP57iG6bwz0onL4d07RpBtGN2XszEn3Mnf/F j8BxUgeLqDbqnroRjBB7lOH4rXvlu0i+ZxSRPNuk9hUcRXgdcLMqJ4YOeVJn6uqW11w1 abru8xuYWAPzY/dtoQfsqN8UG5EyxJ6TQ2H+muRrb/RiWHTNJDH5y1fNn78ybrwd9Boh jbFQ== X-Gm-Message-State: APt69E1Js82EnbpxJn1hACKuC5Vkr3LOjgQLtCiGAOboeZgbJe0tM1bD W3w8jT8ezl6dFwdPtAl9n9jazg== X-Received: by 2002:adf:ebc3:: with SMTP id v3-v6mr11103777wrn.33.1529956550957; Mon, 25 Jun 2018 12:55:50 -0700 (PDT) Received: from localhost.localdomain (146-241-36-97.dyn.eolo.it. [146.241.36.97]) by smtp.gmail.com with ESMTPSA id n18-v6sm29072897wrj.58.2018.06.25.12.55.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 12:55:50 -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, Paolo Valente Subject: [PATCH BUGFIX RESEND 1/4] block, bfq: add/remove entity weights correctly Date: Mon, 25 Jun 2018 21:55:34 +0200 Message-Id: <20180625195537.7769-2-paolo.valente@linaro.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180625195537.7769-1-paolo.valente@linaro.org> References: <20180625195537.7769-1-paolo.valente@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org To keep I/O throughput high as often as possible, BFQ performs I/O-dispatch plugging (aka device idling) only when beneficial exactly for throughput, or when needed for service guarantees (low latency, fairness). An important case where the latter condition holds is when the scenario is 'asymmetric' in terms of weights: i.e., when some bfq_queue or whole group of queues has a higher weight, and thus has to receive more service, than other queues or groups. Without dispatch plugging, lower-weight queues/groups may unjustly steal bandwidth to higher-weight queues/groups. To detect asymmetric scenarios, BFQ checks some sufficient conditions. One of these conditions is that active groups have different weights. BFQ controls this condition by maintaining a special set of unique weights of active groups (group_weights_tree). To this purpose, in the function bfq_active_insert/bfq_active_extract BFQ adds/removes the weight of a group to/from this set. Unfortunately, the function bfq_active_extract may happen to be invoked also for a group that is still active (to preserve the correct update of the next queue to serve, see comments in function bfq_no_longer_next_in_service() for details). In this case, removing the weight of the group makes the set group_weights_tree inconsistent. Service-guarantee violations follow. This commit addresses this issue by moving group_weights_tree insertions from their previous location (in bfq_active_insert) into the function __bfq_activate_entity, and by moving group_weights_tree extractions from bfq_active_extract to when the entity that represents a group remains throughly idle, i.e., with no request either enqueued or dispatched. Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 45 +++++++++++++++++++++++++++++++++++++++++---- block/bfq-iosched.h | 7 +++++-- block/bfq-wf2q.c | 24 +++++++++++++----------- 3 files changed, 59 insertions(+), 17 deletions(-) -- 2.16.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 495b9ddb3355..3f32e88c7e9b 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -742,8 +742,9 @@ void bfq_weights_tree_add(struct bfq_data *bfqd, struct bfq_entity *entity, * See the comments to the function bfq_weights_tree_add() for considerations * about overhead. */ -void bfq_weights_tree_remove(struct bfq_data *bfqd, struct bfq_entity *entity, - struct rb_root *root) +void __bfq_weights_tree_remove(struct bfq_data *bfqd, + struct bfq_entity *entity, + struct rb_root *root) { if (!entity->weight_counter) return; @@ -759,6 +760,43 @@ void bfq_weights_tree_remove(struct bfq_data *bfqd, struct bfq_entity *entity, entity->weight_counter = NULL; } +/* + * Invoke __bfq_weights_tree_remove on bfqq and all its inactive + * parent entities. + */ +void bfq_weights_tree_remove(struct bfq_data *bfqd, + struct bfq_queue *bfqq) +{ + struct bfq_entity *entity = bfqq->entity.parent; + + __bfq_weights_tree_remove(bfqd, &bfqq->entity, + &bfqd->queue_weights_tree); + + for_each_entity(entity) { + struct bfq_sched_data *sd = entity->my_sched_data; + + if (sd->next_in_service || sd->in_service_entity) { + /* + * entity is still active, because either + * next_in_service or in_service_entity is not + * NULL (see the comments on the definition of + * next_in_service for details on why + * in_service_entity must be checked too). + * + * As a consequence, the weight of entity is + * not to be removed. In addition, if entity + * is active, then its parent entities are + * active as well, and thus their weights are + * not to be removed either. In the end, this + * loop must stop here. + */ + break; + } + __bfq_weights_tree_remove(bfqd, entity, + &bfqd->group_weights_tree); + } +} + /* * Return expired entry, or NULL to just start from scratch in rbtree. */ @@ -4582,8 +4620,7 @@ static void bfq_completed_request(struct bfq_queue *bfqq, struct bfq_data *bfqd) */ bfqq->budget_timeout = jiffies; - bfq_weights_tree_remove(bfqd, &bfqq->entity, - &bfqd->queue_weights_tree); + bfq_weights_tree_remove(bfqd, bfqq); } now_ns = ktime_get_ns(); diff --git a/block/bfq-iosched.h b/block/bfq-iosched.h index 0f712e03b035..a8a2e5aca4d4 100644 --- a/block/bfq-iosched.h +++ b/block/bfq-iosched.h @@ -827,8 +827,11 @@ struct bfq_data *bic_to_bfqd(struct bfq_io_cq *bic); void bfq_pos_tree_add_move(struct bfq_data *bfqd, struct bfq_queue *bfqq); void bfq_weights_tree_add(struct bfq_data *bfqd, struct bfq_entity *entity, struct rb_root *root); -void bfq_weights_tree_remove(struct bfq_data *bfqd, struct bfq_entity *entity, - struct rb_root *root); +void __bfq_weights_tree_remove(struct bfq_data *bfqd, + struct bfq_entity *entity, + struct rb_root *root); +void bfq_weights_tree_remove(struct bfq_data *bfqd, + struct bfq_queue *bfqq); void bfq_bfqq_expire(struct bfq_data *bfqd, struct bfq_queue *bfqq, bool compensate, enum bfqq_expiration reason); void bfq_put_queue(struct bfq_queue *bfqq); diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c index 4498c43245e2..58cf38fcee05 100644 --- a/block/bfq-wf2q.c +++ b/block/bfq-wf2q.c @@ -499,9 +499,6 @@ static void bfq_active_insert(struct bfq_service_tree *st, if (bfqq) list_add(&bfqq->bfqq_list, &bfqq->bfqd->active_list); #ifdef CONFIG_BFQ_GROUP_IOSCHED - else /* bfq_group */ - bfq_weights_tree_add(bfqd, entity, &bfqd->group_weights_tree); - if (bfqg != bfqd->root_group) bfqg->active_entities++; #endif @@ -601,10 +598,6 @@ static void bfq_active_extract(struct bfq_service_tree *st, if (bfqq) list_del(&bfqq->bfqq_list); #ifdef CONFIG_BFQ_GROUP_IOSCHED - else /* bfq_group */ - bfq_weights_tree_remove(bfqd, entity, - &bfqd->group_weights_tree); - if (bfqg != bfqd->root_group) bfqg->active_entities--; #endif @@ -799,7 +792,7 @@ __bfq_entity_update_weight_prio(struct bfq_service_tree *old_st, if (prev_weight != new_weight) { root = bfqq ? &bfqd->queue_weights_tree : &bfqd->group_weights_tree; - bfq_weights_tree_remove(bfqd, entity, root); + __bfq_weights_tree_remove(bfqd, entity, root); } entity->weight = new_weight; /* @@ -971,7 +964,7 @@ static void bfq_update_fin_time_enqueue(struct bfq_entity *entity, * one of its children receives a new request. * * Basically, this function updates the timestamps of entity and - * inserts entity into its active tree, ater possibly extracting it + * inserts entity into its active tree, after possibly extracting it * from its idle tree. */ static void __bfq_activate_entity(struct bfq_entity *entity, @@ -1015,6 +1008,16 @@ static void __bfq_activate_entity(struct bfq_entity *entity, entity->on_st = true; } +#ifdef BFQ_GROUP_IOSCHED_ENABLED + if (!bfq_entity_to_bfqq(entity)) { /* bfq_group */ + struct bfq_group *bfqg = + container_of(entity, struct bfq_group, entity); + + bfq_weights_tree_add(bfqg->bfqd, entity, + &bfqd->group_weights_tree); + } +#endif + bfq_update_fin_time_enqueue(entity, st, backshifted); } @@ -1664,8 +1667,7 @@ void bfq_del_bfqq_busy(struct bfq_data *bfqd, struct bfq_queue *bfqq, bfqd->busy_queues--; if (!bfqq->dispatched) - bfq_weights_tree_remove(bfqd, &bfqq->entity, - &bfqd->queue_weights_tree); + bfq_weights_tree_remove(bfqd, bfqq); if (bfqq->wr_coeff > 1) bfqd->wr_busy_queues--; From patchwork Mon Jun 25 19:55:35 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 139884 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp4377594lji; Mon, 25 Jun 2018 12:55:59 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJbl6S/TEle/h6GtFHzILD3L8sOSxIxCafgo8NsuxlhbZVCWMjhiNaui4HXKV6RpfPpScoJ X-Received: by 2002:a62:2605:: with SMTP id m5-v6mr3790150pfm.223.1529956559327; Mon, 25 Jun 2018 12:55:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529956559; cv=none; d=google.com; s=arc-20160816; b=o9cuqDYzBqVKkxCQAxocLX1/myauUt+BjxpFbWyj9vXF4Tspc7ogDOyH4FbisS1Uih S0/ypv+UjI4tX1bC+Lxq/Qs2Gm+QwnBeXH/gVjynhrc7XhIE5u6DxtAhLbEro9dIklt+ 2OMp7hDmM05NlpM/EArH21/sn8PlADNg6wtck5jWWK1n7BVIUws00W+tdEILN5ytzRao IV3D0twq2LaQ49uDYlPkwqi8nWtF1yFkSgdnfQVHXB0VjqQWiKvNA7m/U5jCfXoHWrHH F05OkcYnYDJSt46MBvPyDWyiBTR4xGwvZzvdf507ilzCheZaDtIYVn7dkhkhTgov0Ecd jm9A== 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=j7GMIIGaIORm8b6LjrnaeSpizBl5u4j6T5VX4NtEKP0=; b=fAKkTnKkkTa2rSlfgI5CYlk6FXcLkNRIbzhaBPETPsRCgusUdUM0/dY6U7TQ9xF4c2 aODh7sExRQUfE2F7qsE+Ut984/FzUv/7pxc1SOD89EuzMHO91aLSVR6BpmjvV01Xo5mh dcJXMOIFIeeonrVeG0ZOpY1Fyk5U+kTFY/fELy67jEozJk0Donl38d1dTujLXWOeBAd1 26O0MYqG1nL4Y4+PWTeCO2DQrPyelsVBCQnBLIrC+GEd9z3WcsPUi4sU0gNKR9WYGeW0 DkG/cH+EUObv83y+bAhaK3zY5RNTmPGlNzhzO/h/i0uoRPfzE67JDCAuNDblCIK5ov1K Txng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=gQvYuzhK; 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 v12-v6si14642244plo.264.2018.06.25.12.55.58; Mon, 25 Jun 2018 12:55:59 -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=gQvYuzhK; 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 S965100AbeFYTz4 (ORCPT + 31 others); Mon, 25 Jun 2018 15:55:56 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:44122 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965042AbeFYTzx (ORCPT ); Mon, 25 Jun 2018 15:55:53 -0400 Received: by mail-wr0-f193.google.com with SMTP id p12-v6so13232642wrn.11 for ; Mon, 25 Jun 2018 12:55:53 -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=j7GMIIGaIORm8b6LjrnaeSpizBl5u4j6T5VX4NtEKP0=; b=gQvYuzhKyf5+4vtV9Yb7lZ/XQ5uVesz/M1GB+b5Jdp8aqoEPm4/wzV35RD06fmYjKO ouw7xTWeDmnX/QIsWP443pkQDhBZ3IrUzXXb4btWoMYol7Q3cljstUEVHOuDtfUXUKjT d9bdCvxgF7+cOhRi5t3UjFLRMYi8ixOYw5RLg= 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=j7GMIIGaIORm8b6LjrnaeSpizBl5u4j6T5VX4NtEKP0=; b=JPfgJPiTywQ7o0lBE4aRHs+ehyQP4AiTjW5V7UlTXVQR/CDIbU5vIW2vor+Ho7X5Ou V+m1o+mpvZSOmt5w1+htf06At/fxrJbzw4W/1PUVo6AeluXqUMei4BEUr318ZSDBrVG/ IefV5ieBpq5ehaNAuOA2qBjfEiYsJcxUczr1rZl8Qgl8T27CY0zAjVNRUSMal2wuy3kO tk0X0Vtle1ubYfgpiNXBkSFprIFEEj8G3jzsOi1q+CIJVy4CVv1HOJg7JSE6IIX/Rbm3 khqb9zgaLabz3MBTKEBdd4AxgpZALMisN2ZR5BVhmhBQSYr1kbcezzBXorIjE+uswHA7 5JJg== X-Gm-Message-State: APt69E2SdsB6OI+3lJO5LsIMs72CJB3MW2TY1l65gBP4oKwzD+5QQ7VP mcmsb2WQbuIabrZZVhC2A6F5xw== X-Received: by 2002:adf:88e3:: with SMTP id g32-v6mr4282569wrg.62.1529956552337; Mon, 25 Jun 2018 12:55:52 -0700 (PDT) Received: from localhost.localdomain (146-241-36-97.dyn.eolo.it. [146.241.36.97]) by smtp.gmail.com with ESMTPSA id n18-v6sm29072897wrj.58.2018.06.25.12.55.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 12:55:51 -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, Paolo Valente Subject: [PATCH BUGFIX RESEND 2/4] block, bfq: do not expire a queue that will deserve dispatch plugging Date: Mon, 25 Jun 2018 21:55:35 +0200 Message-Id: <20180625195537.7769-3-paolo.valente@linaro.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180625195537.7769-1-paolo.valente@linaro.org> References: <20180625195537.7769-1-paolo.valente@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For some bfq_queues, BFQ plugs I/O dispatching when the queue becomes idle, and keeps the plug until a new request of the queue arrives, or a timeout fires. BFQ does so either to boost throughput or to preserve service guarantees for the queue. More precisely, for such a queue, plugging starts when the queue happens to have either no request enqueued, or no request in flight, that is, no request already dispatched but not yet completed. On the opposite end, BFQ may happen to expire a queue with no request enqueued, without doing any plugging, if the queue still has some request in flight. Unfortunately, such a premature expiration causes the queue to lose its chance to enjoy dispatch plugging a moment later, i.e., when its in-flight requests finally get completed. This breaks service guarantees for the queue. This commit prevents BFQ from expiring an empty queue if the latter still has in-flight requests. Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 36 +++++++++++++++++++++++++++++++++--- 1 file changed, 33 insertions(+), 3 deletions(-) -- 2.16.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 3f32e88c7e9b..4fd4f1996498 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -3597,8 +3597,14 @@ static struct bfq_queue *bfq_select_queue(struct bfq_data *bfqd) bfq_log_bfqq(bfqd, bfqq, "select_queue: already in-service queue"); + /* + * Do not expire bfqq for budget timeout if bfqq may be about + * to enjoy device idling. The reason why, in this case, we + * prevent bfqq from expiring is the same as in the comments + * on the case where bfq_bfqq_must_idle() returns true, in + * bfq_completed_request(). + */ if (bfq_may_expire_for_budg_timeout(bfqq) && - !bfq_bfqq_wait_request(bfqq) && !bfq_bfqq_must_idle(bfqq)) goto expire; @@ -4674,8 +4680,32 @@ static void bfq_completed_request(struct bfq_queue *bfqq, struct bfq_data *bfqd) * or if we want to idle in case it has no pending requests. */ if (bfqd->in_service_queue == bfqq) { - if (bfqq->dispatched == 0 && bfq_bfqq_must_idle(bfqq)) { - bfq_arm_slice_timer(bfqd); + if (bfq_bfqq_must_idle(bfqq)) { + if (bfqq->dispatched == 0) + bfq_arm_slice_timer(bfqd); + /* + * If we get here, we do not expire bfqq, even + * if bfqq was in budget timeout or had no + * more requests (as controlled in the next + * conditional instructions). The reason for + * not expiring bfqq is as follows. + * + * Here bfqq->dispatched > 0 holds, but + * bfq_bfqq_must_idle() returned true. This + * implies that, even if no request arrives + * for bfqq before bfqq->dispatched reaches 0, + * bfqq will, however, not be expired on the + * completion event that causes bfqq->dispatch + * to reach zero. In contrast, on this event, + * bfqq will start enjoying device idling + * (I/O-dispatch plugging). + * + * But, if we expired bfqq here, bfqq would + * not have the chance to enjoy device idling + * when bfqq->dispatched finally reaches + * zero. This would expose bfqq to violation + * of its reserved service guarantees. + */ return; } else if (bfq_may_expire_for_budg_timeout(bfqq)) bfq_bfqq_expire(bfqd, bfqq, false, From patchwork Mon Jun 25 19:55:36 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 139886 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp4377905lji; Mon, 25 Jun 2018 12:56:27 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKR2ifYxEoo5bu11rcAqEzr4VbvTh4NKb4iIqe0oafD+Xg5UkeFFzbG3vCQPsOETEEUCzjN X-Received: by 2002:a17:902:68:: with SMTP id 95-v6mr7311437pla.178.1529956586895; Mon, 25 Jun 2018 12:56:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529956586; cv=none; d=google.com; s=arc-20160816; b=g6oDWdeXG0EYa7YrmmNLYC52IPdahCXyBQzXd81cwJuoO5r29T4FpyyhtbHQAzLIK6 KtESinFS2gJ+sMdvmPVw8wQeWYFOlPv5oOB+7QiFlQx/P9V0pz5OAMA1RfQGmMsdz0Z1 vUS1YdF8tw51e4n7aboEZyeMJaomWKK7YxAiO3N2X4NLsTEGKIjcugDAGSmjJdFqcnZA lXHFxrgQ8IZ5eoyoK0xyY/h2McN7mQh/0YJzXZW9Ij9g4yUWrixGFO8Hn8Yqsm/zQQuC xlTes2sVvbxAq0K7e67fwIE4N3A2teAqq3Ma+EZLv5DhG39bhpHqDvztWqe9amqLYdmy 8pbA== 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=LKtII1UD6euL+L9WiOdbqv9eZt0vnFL0OuzsmpLoWpw=; b=Sjk7c8vS79LtHHuivob3Su98RE9Ht4iMySXloXqY6PDM6sXxCojT6Pu3guSKMJl/QG bVuPzk9jRH83YcgANMPwsIpKkw+Is29rg/g7njjQL9bNaeCn9vHL8nU5A30vu3o0iS3W k3L5umCKtRB/5q+kt1QiwTgbTsHE5lM7QIAzXM8S0bDQjYktyRUOIDA4YtMQ4ZycbmtS akKjeCetTAbE4JR/05xhTHI2ugvF1x/sY8140R5eihmmNoev/8si81mXwaXikG4v/zdU cS+uCQhkWcL3kOS7MC3aHzzMSg+BPGMfCDr/jb+6tcDGhhpCKxkRJr8u5VA/1njy2nSb JoGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=I5l+zteD; 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 x10-v6si14300621plv.1.2018.06.25.12.56.26; Mon, 25 Jun 2018 12:56:26 -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=I5l+zteD; 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 S965136AbeFYT4Y (ORCPT + 31 others); Mon, 25 Jun 2018 15:56:24 -0400 Received: from mail-wr0-f196.google.com ([209.85.128.196]:46344 "EHLO mail-wr0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965048AbeFYTzz (ORCPT ); Mon, 25 Jun 2018 15:55:55 -0400 Received: by mail-wr0-f196.google.com with SMTP id l14-v6so9802966wrq.13 for ; Mon, 25 Jun 2018 12:55:54 -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=LKtII1UD6euL+L9WiOdbqv9eZt0vnFL0OuzsmpLoWpw=; b=I5l+zteDLPVsIucfXHvKJbeVUX2QkVzZJkmjcFzOeEwhiDrm7k7HmM5BbBlZp6jy+A wTz1DXQMlmBSiggKM31vuzIUhd7cVg1xiM+wb3a75usVzAg/u8fKec6D6aGz8Vb/NvDQ 7t4239dR9gvbXU2j51bysV/9Hiak5Huyvuja4= 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=LKtII1UD6euL+L9WiOdbqv9eZt0vnFL0OuzsmpLoWpw=; b=kWu8xtwu292IwT/wXaJoYYp3hXJmlATqD8et+fwle7AvXQoQHUVs7XOIKt20jWv/tg unOzqH4G+9UsYdvtfCK2VxUumoS1nj80MaL9Fn001BH2fEBELATHYWHkMzfz3QvGosD6 hBzmKugOZDZOEO0YJko0EUXkJR02wPJUxVntGQfgr/7zSVks/O7mSJ1Y7pk6RxkzwxqT H0in80i+E4zG9Z7g3TNy4POpxusbGX0mb2f4s1z4FHlHvVxgnEMG8QCxFYyoildSsOTJ +qD+8zzKtrLTWXyUQzOx/Lp3paWMlMr+im6+0/c6OvIFU2T+6vUBHSrODei/yWH5mbjM ZbDA== X-Gm-Message-State: APt69E31mMcVJVLlDDFobWLMjltyrz3iXGkFwVj35I2k/4TMcJMmxOo0 TQnhWqWUL/21uXbexj83qhZSYA== X-Received: by 2002:adf:ac66:: with SMTP id v93-v6mr3460980wrc.7.1529956553730; Mon, 25 Jun 2018 12:55:53 -0700 (PDT) Received: from localhost.localdomain (146-241-36-97.dyn.eolo.it. [146.241.36.97]) by smtp.gmail.com with ESMTPSA id n18-v6sm29072897wrj.58.2018.06.25.12.55.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 12:55:52 -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, Paolo Valente Subject: [PATCH BUGFIX RESEND 3/4] block, bfq: fix service being wrongly set to zero in case of preemption Date: Mon, 25 Jun 2018 21:55:36 +0200 Message-Id: <20180625195537.7769-4-paolo.valente@linaro.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180625195537.7769-1-paolo.valente@linaro.org> References: <20180625195537.7769-1-paolo.valente@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If - a bfq_queue Q preempts another queue, because one request of Q arrives in time, - but, after this preemption, Q is not the queue that is set in service, then Q->entity.service is set to 0 when Q is eventually set in service. But Q should have continued receiving service with its old budget (which is why preemption has occurred) and its old service. This commit addresses this issue by resetting service on queue real expiration. Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 34 ++++++++++++++++++++++++++++------ block/bfq-wf2q.c | 6 ------ 2 files changed, 28 insertions(+), 12 deletions(-) -- 2.16.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index 4fd4f1996498..d579cc8e0db6 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -1382,18 +1382,30 @@ static bool bfq_bfqq_update_budg_for_activation(struct bfq_data *bfqd, * remain unchanged after such an expiration, and the * following statement therefore assigns to * entity->budget the remaining budget on such an - * expiration. For clarity, entity->service is not - * updated on expiration in any case, and, in normal - * operation, is reset only when bfqq is selected for - * service (see bfq_get_next_queue). + * expiration. */ entity->budget = min_t(unsigned long, bfq_bfqq_budget_left(bfqq), bfqq->max_budget); + /* + * At this point, we have used entity->service to get + * the budget left (needed for updating + * entity->budget). Thus we finally can, and have to, + * reset entity->service. The latter must be reset + * because bfqq would otherwise be charged again for + * the service it has received during its previous + * service slot(s). + */ + entity->service = 0; + return true; } + /* + * We can finally complete expiration, by setting service to 0. + */ + entity->service = 0; entity->budget = max_t(unsigned long, bfqq->max_budget, bfq_serv_to_charge(bfqq->next_rq, bfqq)); bfq_clear_bfqq_non_blocking_wait_rq(bfqq); @@ -3271,11 +3283,21 @@ void bfq_bfqq_expire(struct bfq_data *bfqd, ref = bfqq->ref; __bfq_bfqq_expire(bfqd, bfqq); + if (ref == 1) /* bfqq is gone, no more actions on it */ + return; + /* mark bfqq as waiting a request only if a bic still points to it */ - if (ref > 1 && !bfq_bfqq_busy(bfqq) && + if (!bfq_bfqq_busy(bfqq) && reason != BFQQE_BUDGET_TIMEOUT && - reason != BFQQE_BUDGET_EXHAUSTED) + reason != BFQQE_BUDGET_EXHAUSTED) { bfq_mark_bfqq_non_blocking_wait_rq(bfqq); + /* + * Not setting service to 0, because, if the next rq + * arrives in time, the queue will go on receiving + * service with this same budget (as if it never expired) + */ + } else + entity->service = 0; } /* diff --git a/block/bfq-wf2q.c b/block/bfq-wf2q.c index 58cf38fcee05..dbc07b456059 100644 --- a/block/bfq-wf2q.c +++ b/block/bfq-wf2q.c @@ -1544,12 +1544,6 @@ struct bfq_queue *bfq_get_next_queue(struct bfq_data *bfqd) entity = sd->next_in_service; sd->in_service_entity = entity; - /* - * Reset the accumulator of the amount of service that - * the entity is about to receive. - */ - entity->service = 0; - /* * If entity is no longer a candidate for next * service, then it must be extracted from its active From patchwork Mon Jun 25 19:55:37 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Valente X-Patchwork-Id: 139885 Delivered-To: patch@linaro.org Received: by 2002:a2e:970d:0:0:0:0:0 with SMTP id r13-v6csp4377632lji; Mon, 25 Jun 2018 12:56:02 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIanN33bn9bOjczf7yqQWTgq79lTtCWBWjK1sHCgSFJGTmy+AtpPg8sMCWRoIU8QiIyIVyW X-Received: by 2002:a62:8703:: with SMTP id i3-v6mr14394489pfe.115.1529956561939; Mon, 25 Jun 2018 12:56:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529956561; cv=none; d=google.com; s=arc-20160816; b=U4hf0hzwtivShTwnTZ1P/HRKYiAGTn2kLCWt8f8y/EP92qJeHxtwEGjDl/jHG+coOU V9FYUSpDhgwefSHBN4gjHBxA38njBT5yWo6ilarn5sgq0gVGEd2bMhQ0xzLdSPG/MFfh qvk5nwVBHSXFuwqO4QCmcy+sSidSUYMftCkEioKl55eX6w/x116dLzTnm67zNK6qujSd wYndOUXdYPalAuJWB68jkqJrHMsRcbghy2w4HwK6f+6MFwMF3JYWDRRlFCAN+8POCwuK UMb6vjABFU2sFk9808AdA38g0mr1qtX61VGIowVvNOoCK3F3uHZjScxQyhJOYtjPrEOE mPaA== 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=v6cDwd+/4eCmk1MGKxYMdFTnaz1gvwnSx0DFbMN/pjg=; b=hneSLl5VY4yA5thmKJHKWEq/pYJvKBxK48/rO1Pp15IdjbN0M/KnMd8G0zBcdVTRyM +0fX15hnID1o6stscA+D3SVcWsczjsKGnGGIJlYp6GCF7RewDV1HifDpOZrhq/o/9yMv x+mi4+Tga5Fyn5pi1Q3Y/3xAHfHpruLxGXffuC1rZiNHUQATY+INQyC04gdNQBxMG86P Z+lU+/y4ZnIqOrJL2ai5sn32nDT/2x5nrNJ9Rv92683U0Xx5pDYDpZvFvY2/l4IKHh5W s/mtAMPeuLCupqsM2wt7fcq/Zu3aZhfg/mGe8J7me+OFkD4Dzhz3O0L2NEIG/JNolwQm z/LA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=FElmUAAn; 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 v12-v6si14642244plo.264.2018.06.25.12.56.01; Mon, 25 Jun 2018 12:56:01 -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=FElmUAAn; 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 S965117AbeFYT4A (ORCPT + 31 others); Mon, 25 Jun 2018 15:56:00 -0400 Received: from mail-wr0-f193.google.com ([209.85.128.193]:42522 "EHLO mail-wr0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965094AbeFYTz4 (ORCPT ); Mon, 25 Jun 2018 15:55:56 -0400 Received: by mail-wr0-f193.google.com with SMTP id w10-v6so14865858wrk.9 for ; Mon, 25 Jun 2018 12:55:55 -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=v6cDwd+/4eCmk1MGKxYMdFTnaz1gvwnSx0DFbMN/pjg=; b=FElmUAAnN+fKF7otS+Y51Dvw5/gIlaGZ1rJi8U+p8MnWXEEHAiKpNeQjNDVZID1Aw5 BlKhhr/Dsm82A5X9drgQfgsT4n2JzlB5QaBp78kij8Sm5/ZVwwqAtVW25dNbjzTUb4Hv pdO/dQIyUyxoZeYKl3hCH0Hvc0cZ0nYAWoyg8= 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=v6cDwd+/4eCmk1MGKxYMdFTnaz1gvwnSx0DFbMN/pjg=; b=poNDPlzIoYIJzGyy4wy9pNU0+vJqLqcPS3t1UXAoZE4LsNR+1k/Xdyqb5ToR8GEnnq d/H6j0eKdgVdnu0nKINSk/v9C3x/ZxIvU/b1l4I3OWpXriO2gDBmickoKaGDVqJDs7Jh H/H1rJ3cK+Y7gqtQY2IsLnwdec4K/SkzwTg625E+jUCldz7RPV4yT33aUj0Ne3QzLVfN hZiy9AT5hrTGTkJOQVUTQPN7r9t1tsrc4Awe67wH1ftJs5RSA0tMP9vbrDzsgwRoaTSr zw1zQACgBFpyQWvD8EpIHBdNZmpF/3GY7Gt8R4oe1GLlfPZ7IwlPnf/rm6Uf4BDssLuk fT1Q== X-Gm-Message-State: APt69E2C1IX+KtGCe3dFGslnYFNeHlyDN9gCCGQ9f0g0kzrLmUVqrfPx zfsZCEBH3ZnfGw/ze0IxHKimFw== X-Received: by 2002:adf:a706:: with SMTP id c6-v6mr11730299wrd.61.1529956555025; Mon, 25 Jun 2018 12:55:55 -0700 (PDT) Received: from localhost.localdomain (146-241-36-97.dyn.eolo.it. [146.241.36.97]) by smtp.gmail.com with ESMTPSA id n18-v6sm29072897wrj.58.2018.06.25.12.55.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jun 2018 12:55:54 -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, Paolo Valente Subject: [PATCH BUGFIX RESEND 4/4] block, bfq: give a better name to bfq_bfqq_may_idle Date: Mon, 25 Jun 2018 21:55:37 +0200 Message-Id: <20180625195537.7769-5-paolo.valente@linaro.org> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180625195537.7769-1-paolo.valente@linaro.org> References: <20180625195537.7769-1-paolo.valente@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The actual goal of the function bfq_bfqq_may_idle is to tell whether it is better to perform device idling (more precisely: I/O-dispatch plugging) for the input bfq_queue, either to boost throughput or to preserve service guarantees. This commit improves the name of the function accordingly. Signed-off-by: Paolo Valente --- block/bfq-iosched.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) -- 2.16.1 diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index d579cc8e0db6..41d9036b1822 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -634,7 +634,7 @@ static bool bfq_differentiated_weights(struct bfq_data *bfqd) * The following function returns true if every queue must receive the * same share of the throughput (this condition is used when deciding * whether idling may be disabled, see the comments in the function - * bfq_bfqq_may_idle()). + * bfq_better_to_idle()). * * Such a scenario occurs when: * 1) all active queues have the same weight, @@ -3355,7 +3355,7 @@ static bool bfq_may_expire_for_budg_timeout(struct bfq_queue *bfqq) * issues taken into account are not trivial. We discuss these issues * individually while introducing the variables. */ -static bool bfq_bfqq_may_idle(struct bfq_queue *bfqq) +static bool bfq_better_to_idle(struct bfq_queue *bfqq) { struct bfq_data *bfqd = bfqq->bfqd; bool rot_without_queueing = @@ -3588,19 +3588,19 @@ static bool bfq_bfqq_may_idle(struct bfq_queue *bfqq) } /* - * If the in-service queue is empty but the function bfq_bfqq_may_idle + * If the in-service queue is empty but the function bfq_better_to_idle * returns true, then: * 1) the queue must remain in service and cannot be expired, and * 2) the device must be idled to wait for the possible arrival of a new * request for the queue. - * See the comments on the function bfq_bfqq_may_idle for the reasons + * See the comments on the function bfq_better_to_idle for the reasons * why performing device idling is the best choice to boost the throughput - * and preserve service guarantees when bfq_bfqq_may_idle itself + * and preserve service guarantees when bfq_better_to_idle itself * returns true. */ static bool bfq_bfqq_must_idle(struct bfq_queue *bfqq) { - return RB_EMPTY_ROOT(&bfqq->sort_list) && bfq_bfqq_may_idle(bfqq); + return RB_EMPTY_ROOT(&bfqq->sort_list) && bfq_better_to_idle(bfqq); } /* @@ -3686,7 +3686,7 @@ static struct bfq_queue *bfq_select_queue(struct bfq_data *bfqd) * may idle after their completion, then keep it anyway. */ if (bfq_bfqq_wait_request(bfqq) || - (bfqq->dispatched != 0 && bfq_bfqq_may_idle(bfqq))) { + (bfqq->dispatched != 0 && bfq_better_to_idle(bfqq))) { bfqq = NULL; goto keep_queue; } @@ -4734,7 +4734,7 @@ static void bfq_completed_request(struct bfq_queue *bfqq, struct bfq_data *bfqd) BFQQE_BUDGET_TIMEOUT); else if (RB_EMPTY_ROOT(&bfqq->sort_list) && (bfqq->dispatched == 0 || - !bfq_bfqq_may_idle(bfqq))) + !bfq_better_to_idle(bfqq))) bfq_bfqq_expire(bfqd, bfqq, false, BFQQE_NO_MORE_REQUESTS); }