mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Jeff Moyer <jmoyer@redhat.com>, Mike Snitzer <snitzer@redhat.com>,
	Jens Axboe <axboe@kernel.dk>,
	Markus Trippelsdorf <markus@trippelsdorf.de>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	linux-kernel@vger.kernel.org,
	Chris Mason <chris.mason@oracle.com>
Subject: Re: [PATCH] block: eliminate ELEVATOR_INSERT_REQUEUE (was: Re: elevator private data for REQ_FLUSH)
Date: Wed, 30 Mar 2011 09:41:23 +0200	[thread overview]
Message-ID: <20110330074123.GA17523@htj.dyndns.org> (raw)
In-Reply-To: <20110329175458.GE24485@redhat.com>

On Tue, Mar 29, 2011 at 01:54:58PM -0400, Vivek Goyal wrote:
> What is the significance of REQ_SOFTBARRIER? Why it should be set for all
> INSERT_FRONT and requeue requests.
> 
> With flush logic we got rid of all hardbarriers and hence there is no
> notion of ordering as such. One has to wait for request to finish to
> enforce ordering.
> 
> Should we get rid of softbarriers too?

REQ_SOFTBARRIER makes sure that other requests don't pass the barrier
ones when dispatched from the elevator to the dispatch queue.  When
the request is being inserted explicitly at front, dispatching other
requests in front of it is a bit, umm, weird.

IIRC, at least in the requeue path, some drivers depend on front
queueing for forward progress guarantee.  Forward progress for
prepping is guaranteed by mempool (or something like that) and when
the request is retried, it should stay at the front of the queue;
otherwise, prepping can stall with prepped requests stuck behind
unprepped ones.

Although flush requests don't need REQ_SOFTBARRIER anymore, I don't
think removing it would bring much benefit either, so no reason to
change it just for that reason.

Thanks.

-- 
tejun

  reply	other threads:[~2011-03-30  7:41 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-25 15:15 [OOPS] elevator private data for REQ_FLUSH Sergey Senozhatsky
2011-03-25 15:22 ` Markus Trippelsdorf
2011-03-25 15:40   ` Mike Snitzer
2011-03-25 15:50     ` Jens Axboe
2011-03-25 18:54       ` Mike Snitzer
2011-03-25 19:50         ` Jens Axboe
2011-03-26  4:21           ` Mike Snitzer
2011-03-28  8:23             ` Tejun Heo
2011-03-28 22:15               ` [PATCH] block: eliminate ELEVATOR_INSERT_REQUEUE (was: Re: elevator private data for REQ_FLUSH) Mike Snitzer
2011-03-29 11:56                 ` [PATCH] block: eliminate ELEVATOR_INSERT_REQUEUE Jens Axboe
2011-03-29 14:18                   ` Mike Snitzer
2011-03-29 18:25                   ` [PATCH] " Christoph Hellwig
2011-03-30  7:42                     ` Tejun Heo
2011-03-30  7:53                     ` Jens Axboe
2011-03-29 14:13                 ` [PATCH] block: eliminate ELEVATOR_INSERT_REQUEUE (was: Re: elevator private data for REQ_FLUSH) Jeff Moyer
2011-03-29 17:54                   ` Vivek Goyal
2011-03-30  7:41                     ` Tejun Heo [this message]
2011-03-30  7:57                       ` Tejun Heo
2011-03-30  7:59                         ` [PATCH] block: eliminate ELEVATOR_INSERT_REQUEUE Jens Axboe
2011-03-30  8:02                           ` Tejun Heo
2011-03-30 10:16                             ` Jens Axboe
2011-03-30 11:20                               ` Tejun Heo
2011-03-30 11:23                                 ` Jens Axboe
2011-03-30 11:21                               ` Sergey Senozhatsky
2011-03-30 11:22                                 ` Jens Axboe
2011-03-30 11:49                                   ` Sergey Senozhatsky
2011-03-30 13:46                             ` Vivek Goyal
2011-03-30 13:49                               ` Tejun Heo
2011-03-30 14:01                             ` Mike Snitzer
2011-03-30 14:27                               ` Tejun Heo
2011-03-30 15:22                                 ` Vivek Goyal
2011-03-30 15:30                                   ` Tejun Heo
2011-03-30 17:13                                     ` Jens Axboe
2011-03-30 17:32                                       ` Tejun Heo
2011-03-30 17:56                                       ` Jeff Moyer
2011-03-30 18:12                                         ` Jens Axboe
2011-03-25 15:57   ` [OOPS] elevator private data for REQ_FLUSH Jens Axboe
2011-03-25 16:03     ` Markus Trippelsdorf

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=20110330074123.GA17523@htj.dyndns.org \
    --to=tj@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=chris.mason@oracle.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus@trippelsdorf.de \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=snitzer@redhat.com \
    --cc=vgoyal@redhat.com \
    /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®