search for: do_req

...request(q)) != NULL) { > + vblk = req->rq_disk->private_data; > + > + vbr = mempool_alloc(vblk->pool, GFP_ATOMIC); > + if (!vbr) > + goto stop; > + > + BUG_ON(req->nr_phys_segments > ARRAY_SIZE(vblk->sg)); > + vbr->req = req; > + if (!do_req(q, vblk, vbr)) > + goto stop; > + blkdev_dequeue_request(req); > + } > + > +sync: > + if (vblk) this check looks bogus, as vblk->pool has been accessed unconditionally above > + vblk->vq->ops->sync(vblk->vq); > + return; > + > +stop: &...

...request(q)) != NULL) { > + vblk = req->rq_disk->private_data; > + > + vbr = mempool_alloc(vblk->pool, GFP_ATOMIC); > + if (!vbr) > + goto stop; > + > + BUG_ON(req->nr_phys_segments > ARRAY_SIZE(vblk->sg)); > + vbr->req = req; > + if (!do_req(q, vblk, vbr)) > + goto stop; > + blkdev_dequeue_request(req); > + } > + > +sync: > + if (vblk) this check looks bogus, as vblk->pool has been accessed unconditionally above > + vblk->vq->ops->sync(vblk->vq); > + return; > + > +stop: &...

..._blk.c @@ -69,6 +69,8 @@ static void blk_done(struct virtqueue *v /* In case queue is stopped waiting for more buffers. */ blk_start_queue(vblk->disk->queue); spin_unlock_irqrestore(&vblk->lock, flags); + + vq->vq_ops->enable_cb(vq); } static bool do_req(struct request_queue *q, struct virtio_blk *vblk, Since this does not check the return status from enable_cb, it seems we could loose an interrupt if it arrives between poll and callback enable? Same might apply to other devices. Thanks, -- MST

..._blk.c @@ -69,6 +69,8 @@ static void blk_done(struct virtqueue *v /* In case queue is stopped waiting for more buffers. */ blk_start_queue(vblk->disk->queue); spin_unlock_irqrestore(&vblk->lock, flags); + + vq->vq_ops->enable_cb(vq); } static bool do_req(struct request_queue *q, struct virtio_blk *vblk, Since this does not check the return status from enable_cb, it seems we could loose an interrupt if it arrives between poll and callback enable? Same might apply to other devices. Thanks, -- MST

This is fairly simple: we create a request pointing at the 1k kmalloc, then just change the type so our do_req() knows to mark it as a GET_ID for the server. Seems to work here; the only issue is that the error didn't get passed back from __blk_end_request_all to blk_execute_rq, so we set ->errors to 1 on error. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Jens Axboe <axboe...

This is fairly simple: we create a request pointing at the 1k kmalloc, then just change the type so our do_req() knows to mark it as a GET_ID for the server. Seems to work here; the only issue is that the error didn't get passed back from __blk_end_request_all to blk_execute_rq, so we set ->errors to 1 on error. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> Cc: Jens Axboe <axboe...

...io_scsi_inhdr in_hdr; @@ -99,7 +95,6 @@ static void blk_done(struct virtqueue *vq) } __blk_end_request_all(vbr->req, error); - list_del(&vbr->list); mempool_free(vbr, vblk->pool); } /* In case queue is stopped waiting for more buffers. */ @@ -184,7 +179,6 @@ static bool do_req(struct request_queue *q, struct virtio_blk *vblk, return false; } - list_add_tail(&vbr->list, &vblk->reqs); return true; } @@ -408,7 +402,6 @@ static int __devinit virtblk_probe(struct virtio_device *vdev) goto out_free_index; } - INIT_LIST_HEAD(&vblk->reqs);...

...io_scsi_inhdr in_hdr; @@ -99,7 +95,6 @@ static void blk_done(struct virtqueue *vq) } __blk_end_request_all(vbr->req, error); - list_del(&vbr->list); mempool_free(vbr, vblk->pool); } /* In case queue is stopped waiting for more buffers. */ @@ -184,7 +179,6 @@ static bool do_req(struct request_queue *q, struct virtio_blk *vblk, return false; } - list_add_tail(&vbr->list, &vblk->reqs); return true; } @@ -408,7 +402,6 @@ static int __devinit virtblk_probe(struct virtio_device *vdev) goto out_free_index; } - INIT_LIST_HEAD(&vblk->reqs);...

Hi, Jens & Rusty This version is rebased against linux-next which resolves the conflict with Paolo Bonzini's 'virtio-blk: allow toggling host cache between writeback and writethrough' patch. Patch 1/3 and 2/3 applies on linus's master as well. Since Rusty will pick up patch 3/3 so the changes to block core (adding blk_bio_map_sg()) will have a user. Jens, could you please

Hi, Jens & Rusty This version is rebased against linux-next which resolves the conflict with Paolo Bonzini's 'virtio-blk: allow toggling host cache between writeback and writethrough' patch. Patch 1/3 and 2/3 applies on linus's master as well. Since Rusty will pick up patch 3/3 so the changes to block core (adding blk_bio_map_sg()) will have a user. Jens, could you please

This patchset implements bio-based IO path for virito-blk to improve performance. Fio test shows it gives, 28%, 24%, 21%, 16% IOPS boost and 32%, 17%, 21%, 16% latency improvement for sequential read/write, random read/write respectively. Asias He (2): block: Add blk_bio_map_sg() helper virtio-blk: Add bio-based IO path for virtio-blk block/blk-merge.c | 63 ++++++++++++++

This patchset implements bio-based IO path for virito-blk to improve performance. Fio test shows it gives, 28%, 24%, 21%, 16% IOPS boost and 32%, 17%, 21%, 16% latency improvement for sequential read/write, random read/write respectively. Asias He (2): block: Add blk_bio_map_sg() helper virtio-blk: Add bio-based IO path for virtio-blk block/blk-merge.c | 63 ++++++++++++++

When user hot-unplug a disk which is busy serving I/O, __blk_run_queue might be unable to drain all the requests. As a result, the blk_drain_queue() would loop forever and blk_cleanup_queue would not return. So hot-unplug will fail. This patch adds a callback in blk_drain_queue() for low lever driver to abort requests. Currently, this is useful for virtio-blk to do cleanup in hot-unplug. Cc:

When user hot-unplug a disk which is busy serving I/O, __blk_run_queue might be unable to drain all the requests. As a result, the blk_drain_queue() would loop forever and blk_cleanup_queue would not return. So hot-unplug will fail. This patch adds a callback in blk_drain_queue() for low lever driver to abort requests. Currently, this is useful for virtio-blk to do cleanup in hot-unplug. Cc:

Hi, all This version reworked on REQ_FLUSH and REQ_FUA support as suggested by Christoph and dropped the block core bits since Jens has picked them up. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%,

Hi, all This version reworked on REQ_FLUSH and REQ_FUA support as suggested by Christoph and dropped the block core bits since Jens has picked them up. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%,

Hi, all Changes in v7: - Using vbr->flags to trace request type - Dropped unnecessary struct virtio_blk *vblk parameter - Reuse struct virtblk_req in bio done function - Added performance data on normal SATA device and the reason why make it optional Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential

Hi, all Changes in v7: - Using vbr->flags to trace request type - Dropped unnecessary struct virtio_blk *vblk parameter - Reuse struct virtblk_req in bio done function - Added performance data on normal SATA device and the reason why make it optional Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential

This patchset implements bio-based IO path for virito-blk to improve performance. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%, 17%, 21%, 16% 2) Fusion IO device With bio-based IO path, sequential

This patchset implements bio-based IO path for virito-blk to improve performance. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%, 17%, 21%, 16% 2) Fusion IO device With bio-based IO path, sequential