Re: [PATCH scsi-misc-2.6 01/05] scsi: make blk layer set REQ_SOFTBARRIER when a request is dispatched

From: Jens Axboe (axboe_at_suse.de)
Date: 04/20/05

  • Next message: Takashi Ikebe: "Re: [PATCH x86_64] Live Patching Function on 2.6.11.7" 
    Date:	Wed, 20 Apr 2005 10:38:55 +0200
To: Tejun Heo <htejun@gmail.com>

    On Wed, Apr 20 2005, Tejun Heo wrote:
    > Nick Piggin wrote:
    > > On Wed, 2005-04-20 at 16:40 +0900, Tejun Heo wrote:
    > >
    > >> Hello, Jens.
    > >>
    > >>On Wed, Apr 20, 2005 at 08:30:10AM +0200, Jens Axboe wrote:
    > >>
    > >>>Do it on requeue, please - not on the initial spotting of the request.
    > >>
    > >> This is the reworked version of the patch. It sets REQ_SOFTBARRIER
    > >>in two places - in elv_next_request() on BLKPREP_DEFER and in
    > >>blk_requeue_request().
    > >>
    > >> Other patches apply cleanly with this patch or the original one and
    > >>the end result is the same, so take your pick. :-)
    > >>
    > >
    > >
    > > I'm not sure that you need *either* one.
    > >
    > > As far as I'm aware, REQ_SOFTBARRIER is used when feeding requests
    > > into the top of the block layer, and is used to guarantee the device
    > > driver gets the requests in a specific ordering.
    > >
    > > When dealing with the requests at the other end (ie.
    > > elevator_next_req_fn, blk_requeue_request), then ordering does not
    > > change.
    > >
    > > That is - if you call elevator_next_req_fn and don't dequeue the
    > > request, then that's the same request you'll get next time.
    > >
    > > And blk_requeue_request will push the request back onto the end of
    > > the queue in a LIFO manner.
    > >
    > > So I think adding barriers, apart from not doing anything, confuses
    > > the issue because it suggests there *could* be reordering without
    > > them.
    > >
    > > Or am I completely wrong? It's been a while since I last got into
    > > the code.
    >
    > Well, yeah, all schedulers have dispatch queue (noop has only the
    > dispatch queue) and use them to defer/requeue, so no reordering will
    > happen, but I'm not sure they are required to be like this or just
    > happen to be implemented so.

    Precisely, I feel much better making sure SOFTBARRIER is set so that we
    _know_ that a scheduler following the outlined rules will do the right
    thing.

    > Hmm, well, it seems that setting REQ_SOFTBARRIER on requeue path isn't
    > necessary as we have INSERT_FRONT policy on requeue, and if
    > elv_next_req_fn() is required to return the same request when the
    > request isn't dequeued, you're right and we don't need this patch at
    > all. We are guaranteed that all requeued requests are served in LIFO
    > manner.

    After a requeue, it is not required to return the same request again.

    > BTW, the same un-dequeued request rule is sort of already broken as
    > INSERT_FRONT request passes a returned but un-dequeued request, but,
    > then again, we need this behavior as we have to favor fully-prepped
    > requests over partially-prepped one.

    INSERT_FRONT really should skip requests with REQ_STARTED on the
    dispatch list to be fully safe. 

    -- 
Jens Axboe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Takashi Ikebe: "Re: [PATCH x86_64] Live Patching Function on 2.6.11.7"

    Relevant Pages

    • Re: simplify disksort, please review.
      ... In message, Pawel Jakub Dawidek writes: ... If you issue these two requests just like that, you get no guarantee ... FreeBSD committer ...
      (freebsd-arch)
    • Re: VB5 forcing data to disk
      ... the driver I/O requests, to ensure that such data can be persisted safely. ... For data integrity on disk, ... But modern disks and controllers may cache writes ... out of view of Windows or the file system, so flushing is no guarantee ...
      (microsoft.public.vb.general.discussion)
    • Re: Holiday Worlds Plymouth Cafe menu!
      ... Even Southwest tries to honor "no peanuts" requests if you ask, ... airline can GUARANTEE it (for one thing you never know what other pax will ...
      (rec.roller-coaster)
    • Re: Dinner seatings
      ... You may not get main if you ask for it, but they'll telll you. ... they will tell you what you've *requested.* But in big bold font ... in their brochures it says about dining requests, ... guarantee anything. ...
      (rec.travel.cruises)
    • Re: 2.6.24-rc4-mm1: hostbyte=0x01 driverbyte=0x00 (now bisected)
      ... Do not requeue requests if REQ_FAILFAST is set ... Any requests with the REQ_FAILFAST flag set should not be requeued ... Kill a request for a dead device ... If the devices is blocked we defer normal commands. ...
      (Linux-Kernel)