linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Paolo Valente <paolo.valente@linaro.org>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jan Kara <jack@suse.cz>
Subject: Re: [PATCH BUGFIX/IMPROVEMENT 5/6] block, bfq: keep shared queues out of the waker mechanism
Date: Wed, 3 Feb 2021 12:48:06 +0100	[thread overview]
Message-ID: <20210203114806.GC7094@quack2.suse.cz> (raw)
In-Reply-To: <20210126105102.53102-6-paolo.valente@linaro.org>

On Tue 26-01-21 11:51:01, Paolo Valente wrote:
> Shared queues are likely to receive I/O at a high rate. This may
> deceptively let them be considered as wakers of other queues. But a
> false waker will unjustly steal bandwidth to its supposedly woken
> queue. So considering also shared queues in the waking mechanism may
> cause more control troubles than throughput benefits. This commit
> keeps shared queues out of the waker-detection mechanism.
> 
> Tested-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Paolo Valente <paolo.valente@linaro.org>

Honestly this makes me somewhat nervous. It is just a band aid for a fact
that waker detection is unreliable? There's nothing which prevents
non-shared queue to submit high amounts of IO (e.g. when it uses AIO) as
well as there's nothing which says that shared queues have no wakers (e.g.
jbd2 thread can easily be a waker for a shared queue).

								Honza

> ---
>  block/bfq-iosched.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 0c7e203085f1..23d0dd7bd90f 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -5825,7 +5825,17 @@ static void bfq_completed_request(struct bfq_queue *bfqq, struct bfq_data *bfqd)
>  			1UL<<(BFQ_RATE_SHIFT - 10))
>  		bfq_update_rate_reset(bfqd, NULL);
>  	bfqd->last_completion = now_ns;
> -	bfqd->last_completed_rq_bfqq = bfqq;
> +	/*
> +	 * Shared queues are likely to receive I/O at a high
> +	 * rate. This may deceptively let them be considered as wakers
> +	 * of other queues. But a false waker will unjustly steal
> +	 * bandwidth to its supposedly woken queue. So considering
> +	 * also shared queues in the waking mechanism may cause more
> +	 * control troubles than throughput benefits. Then do not set
> +	 * last_completed_rq_bfqq to bfqq if bfqq is a shared queue.
> +	 */
> +	if (!bfq_bfqq_coop(bfqq))
> +		bfqd->last_completed_rq_bfqq = bfqq;
>  
>  	/*
>  	 * If we are waiting to discover whether the request pattern
> -- 
> 2.20.1
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2021-02-03 11:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-26 10:50 [PATCH BUGFIX/IMPROVEMENT 0/6] block, bfq: third and last batch of fixes and improvements Paolo Valente
2021-01-26 10:50 ` [PATCH BUGFIX/IMPROVEMENT 1/6] block, bfq: always inject I/O of queues blocked by wakers Paolo Valente
2021-01-26 16:17   ` Jens Axboe
2021-02-25 15:58     ` Paolo Valente
2021-01-26 10:50 ` [PATCH BUGFIX/IMPROVEMENT 2/6] block, bfq: put reqs of waker and woken in dispatch list Paolo Valente
2021-01-26 16:18   ` Jens Axboe
2021-01-28 17:54     ` Paolo Valente
2021-02-03 11:01       ` Paolo Valente
2021-02-03 11:43       ` Jan Kara
2021-02-05 10:16         ` Paolo Valente
2021-02-09 17:09           ` Paolo Valente
2021-01-26 10:50 ` [PATCH BUGFIX/IMPROVEMENT 3/6] block, bfq: make shared queues inherit wakers Paolo Valente
2021-01-26 10:51 ` [PATCH BUGFIX/IMPROVEMENT 4/6] block, bfq: fix weight-raising resume with !low_latency Paolo Valente
2021-01-26 10:51 ` [PATCH BUGFIX/IMPROVEMENT 5/6] block, bfq: keep shared queues out of the waker mechanism Paolo Valente
2021-02-03 11:48   ` Jan Kara [this message]
2021-01-26 10:51 ` [PATCH BUGFIX/IMPROVEMENT 6/6] block, bfq: merge bursts of newly-created queues Paolo Valente
2021-01-26 16:15   ` Jens Axboe
2021-02-25 17:25     ` Paolo Valente
2021-01-27  7:34   ` kernel test robot
2021-01-27  9:52   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210203114806.GC7094@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paolo.valente@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).