On 29/05/2015 13:11, Andrey Korolyov wrote:
Sorry for a potential thread hijack, but I`m curious about the reasons
to not making advertised queue depth for non-passthrough backends an
independent tunable, is there any concerns behind that?
It certainly can be made tunable. Usually it is
On Thu, May 28, 2015 at 3:05 PM, Fam Zheng f...@redhat.com wrote:
On Thu, 05/28 13:19, Paolo Bonzini wrote:
On 28/05/2015 13:11, Fam Zheng wrote:
Whoever uses ioeventfd needs to implement pause/resume, yes---not just
dataplane, also regular virtio-blk/virtio-scsi.
However, everyone
On 28/05/2015 04:49, Fam Zheng wrote:
On a second thought, although in this series, we only need to modify
virtio-{scsi,blk}, Wen pointed out that mirror job also wants this during
completion (because bdrv_swap is in a BH after the job coroutine returns).
Mirror needs to pause/resume the
On Thu, 05/28 11:40, Kevin Wolf wrote:
Indeed. blk_pause/resume would handle everything in one central place
in the block layer instead of spreading the logic across all the block
layer users.
Sorry, I'm confused. Do you mean there is a way to implement blk_pause
completely in block layer,
On 28/05/2015 13:11, Fam Zheng wrote:
Whoever uses ioeventfd needs to implement pause/resume, yes---not just
dataplane, also regular virtio-blk/virtio-scsi.
However, everyone else should be okay, because the bottom half runs
immediately and the big QEMU lock is not released in the
On 28/05/2015 13:44, Fam Zheng wrote:
The reason for doing it in the block layer is that it's in one place and
we can be sure that it's applied. We can still in addition modify
specific users to avoid even trying to send requests, but I think it's
good to have the single place that
On 28/05/2015 12:46, Fam Zheng wrote:
Mirror needs to pause/resume the source. It doesn't need to handle
pause/resume of the target, does it?
So, in order for the solution to be general, and complete, this
nofitier list
approach relies on the listening devices to do the
On Thu, 05/28 13:24, Kevin Wolf wrote:
Am 28.05.2015 um 13:00 hat Paolo Bonzini geschrieben:
On 28/05/2015 12:55, Fam Zheng wrote:
Indeed. blk_pause/resume would handle everything in one central place
in the block layer instead of spreading the logic across all the block
layer
On 28/05/2015 12:55, Fam Zheng wrote:
Indeed. blk_pause/resume would handle everything in one central place
in the block layer instead of spreading the logic across all the block
layer users.
Sorry, I'm confused. Do you mean there is a way to implement blk_pause
completely in block
On 28/05/2015 13:24, Kevin Wolf wrote:
Am 28.05.2015 um 13:00 hat Paolo Bonzini geschrieben:
On 28/05/2015 12:55, Fam Zheng wrote:
Indeed. blk_pause/resume would handle everything in one central place
in the block layer instead of spreading the logic across all the block
layer users.
Am 28.05.2015 um 04:49 hat Fam Zheng geschrieben:
On Wed, 05/27 12:43, Paolo Bonzini wrote:
On 27/05/2015 12:10, Kevin Wolf wrote:
Am 27.05.2015 um 11:50 hat Paolo Bonzini geschrieben:
On 27/05/2015 11:07, Kevin Wolf wrote:
This is the first part of what's troubling me with
On Thu, 05/28 13:19, Paolo Bonzini wrote:
On 28/05/2015 13:11, Fam Zheng wrote:
Whoever uses ioeventfd needs to implement pause/resume, yes---not just
dataplane, also regular virtio-blk/virtio-scsi.
However, everyone else should be okay, because the bottom half runs
On Thu, 05/28 13:47, Paolo Bonzini wrote:
On 28/05/2015 13:44, Fam Zheng wrote:
The reason for doing it in the block layer is that it's in one place and
we can be sure that it's applied. We can still in addition modify
specific users to avoid even trying to send requests, but I think
On 22.05.2015 06:54, Fam Zheng wrote:
On Thu, 05/21 15:32, Fam Zheng wrote:
On Thu, 05/21 15:06, Wen Congyang wrote:
On 05/21/2015 02:42 PM, Fam Zheng wrote:
It blocks device IO.
All bdrv_op_block_all/blk_op_block_all callers are taken care of:
- virtio_blk_data_plane_create
-
14 matches
Mail list logo
