All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Valente <paolo.valente@linaro.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	davidezini2@gmail.com
Subject: Re: [PATCH BUGFIX 1/1] block, bfq: honor already-setup queue merges
Date: Thu, 26 Aug 2021 11:16:17 +0200	[thread overview]
Message-ID: <3BDD27BD-F49B-43B6-B41D-F7534B596A9A@linaro.org> (raw)
In-Reply-To: <20210802141352.74353-2-paolo.valente@linaro.org>



> Il giorno 2 ago 2021, alle ore 16:13, Paolo Valente <paolo.valente@linaro.org> ha scritto:
> 
> The function bfq_setup_merge prepares the merging between two
> bfq_queues, say bfqq and new_bfqq. To this goal, it assigns
> bfqq->new_bfqq = new_bfqq. Then, each time some I/O for bfqq arrives,
> the process that generated that I/O is disassociated from bfqq and
> associated with new_bfqq (merging is actually a redirection). In this
> respect, bfq_setup_merge increases new_bfqq->ref in advance, adding
> the number of processes that are expected to be associated with
> new_bfqq.
> 
> Unfortunately, the stable-merging mechanism interferes with this
> setup. After bfqq->new_bfqq has been set by bfq_setup_merge, and
> before all the expected processes have been associated with
> bfqq->new_bfqq, bfqq may happen to be stably merged with a different
> queue than the current bfqq->new_bfqq. In this case, bfqq->new_bfqq
> gets changed. So, some of the processes that have been already
> accounted for in the ref counter of the previous new_bfqq will not be
> associated with that queue.  This creates an unbalance, because those
> references will never be decremented.
> 
> This commit fixes this issue by reestablishing the previous, natural
> behaviour: once bfqq->new_bfqq has been set, it will not be changed
> until all expected redirections have occurred.
> 

Hi Jens,
did you have time to look at this fix?

Thanks,
Paolo


> Signed-off-by: Davide Zini <davidezini2@gmail.com>
> Signed-off-by: Paolo Valente <paolo.valente@linaro.org>
> ---
> block/bfq-iosched.c | 16 +++++++++++++---
> 1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 727955918563..08d9122dd4c0 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -2659,6 +2659,15 @@ bfq_setup_merge(struct bfq_queue *bfqq, struct bfq_queue *new_bfqq)
> 	 * are likely to increase the throughput.
> 	 */
> 	bfqq->new_bfqq = new_bfqq;
> +	/*
> +	 * The above assignment schedules the following redirections:
> +	 * each time some I/O for bfqq arrives, the process that
> +	 * generated that I/O is disassociated from bfqq and
> +	 * associated with new_bfqq. Here we increases new_bfqq->ref
> +	 * in advance, adding the number of processes that are
> +	 * expected to be associated with new_bfqq as they happen to
> +	 * issue I/O.
> +	 */
> 	new_bfqq->ref += process_refs;
> 	return new_bfqq;
> }
> @@ -2721,6 +2730,10 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq,
> {
> 	struct bfq_queue *in_service_bfqq, *new_bfqq;
> 
> +	/* if a merge has already been setup, then proceed with that first */
> +	if (bfqq->new_bfqq)
> +		return bfqq->new_bfqq;
> +
> 	/*
> 	 * Check delayed stable merge for rotational or non-queueing
> 	 * devs. For this branch to be executed, bfqq must not be
> @@ -2822,9 +2835,6 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq,
> 	if (bfq_too_late_for_merging(bfqq))
> 		return NULL;
> 
> -	if (bfqq->new_bfqq)
> -		return bfqq->new_bfqq;
> -
> 	if (!io_struct || unlikely(bfqq == &bfqd->oom_bfqq))
> 		return NULL;
> 
> -- 
> 2.20.1
> 


  reply	other threads:[~2021-08-26  9:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02 14:13 [PATCH BUGFIX 0/1] block, bfq: fix a bug causing a memory leak Paolo Valente
2021-08-02 14:13 ` [PATCH BUGFIX 1/1] block, bfq: honor already-setup queue merges Paolo Valente
2021-08-26  9:16   ` Paolo Valente [this message]
2021-09-02  7:32     ` Paolo Valente
2021-09-02 12:37   ` Jens Axboe

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=3BDD27BD-F49B-43B6-B41D-F7534B596A9A@linaro.org \
    --to=paolo.valente@linaro.org \
    --cc=axboe@kernel.dk \
    --cc=davidezini2@gmail.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.