mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jeff Moyer <jmoyer@redhat.com>
To: Jan Kara <jack@suse.com>
Cc: Jens Axboe <axboe@kernel.dk>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] blk-flush: Queue through IO scheduler when flush not required
Date: Mon, 16 Nov 2015 15:14:51 -0500	[thread overview]
Message-ID: <x494mglr9ac.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <1447334752-31027-1-git-send-email-jack@suse.com> (Jan Kara's message of "Thu, 12 Nov 2015 14:25:52 +0100")

Jan Kara <jack@suse.com> writes:

> Currently blk_insert_flush() just adds flush request to q->queue_head
> when flush is not required. That completely bypasses IO scheduler so
> e.g. CFQ can be idling waiting for new request to arrive and will idle
> through the whole window unnecessarily. Luckily this only happens in
> rare cases as usually checks in generic_make_request_checks() clear
> FLUSH and FUA flags early if they are not needed.

Right.  I think the only way we'd even enter that 'if' block was if the
drive state changed (from WB cache to WT cache) between
generic_make_request_checks and blk_insert_flush.

> When no flushing is actually required, we can easily fix the problem by
> properly queueing the request through the IO scheduler. Ideally IO
> scheduler should be also made aware of requests queued via
> blk_flush_queue_rq(). However inserting flush request through IO
> scheduler can have unwanted side-effects since due to flush batching
> delaying the flush request in IO scheduler will delay all flush requests
> possibly coming from other processes. So we keep adding the request
> directly to q->queue_head.

Reviewed-by: Jeff Moyer <jmoyer@redhat.com>

> Signed-off-by: Jan Kara <jack@suse.com>
> ---
>  block/blk-flush.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block/blk-flush.c b/block/blk-flush.c
> index 9c423e53324a..c81d56ec308f 100644
> --- a/block/blk-flush.c
> +++ b/block/blk-flush.c
> @@ -422,7 +422,7 @@ void blk_insert_flush(struct request *rq)
>  		if (q->mq_ops) {
>  			blk_mq_insert_request(rq, false, false, true);
>  		} else
> -			list_add_tail(&rq->queuelist, &q->queue_head);
> +			q->elevator->type->ops.elevator_add_req_fn(q, rq);
>  		return;
>  	}

  reply	other threads:[~2015-11-16 20:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12 13:25 Jan Kara
2015-11-16 20:14 ` Jeff Moyer [this message]
2015-11-16 22:28 ` 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=x494mglr9ac.fsf@segfault.boston.devel.redhat.com \
    --to=jmoyer@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=jack@suse.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®