This patch introduces these two APIs so that following
patches can support queuing I/O requests and submitting them
at batch for improving I/O performance.
Reviewed-by: Paolo Bonzini
Signed-off-by: Ming Lei
---
block.c | 21 +
include/block/block.h |
Am 01.07.2014 um 09:51 hat Ming Lei geschrieben:
> This patch introduces these two APIs so that following
> patches can support queuing I/O requests and submitting them
> at batch for improving I/O performance.
>
> Reviewed-by: Paolo Bonzini
> Signed-off-by: Ming Lei
> ---
> block.c
On Tue, Jul 1, 2014 at 7:18 PM, Kevin Wolf wrote:
> Am 01.07.2014 um 09:51 hat Ming Lei geschrieben:
>> This patch introduces these two APIs so that following
>> patches can support queuing I/O requests and submitting them
>> at batch for improving I/O performance.
>>
>> Reviewed-by: Paolo Bonzini
On Tue, Jul 1, 2014 at 9:31 PM, Ming Lei wrote:
> On Tue, Jul 1, 2014 at 7:18 PM, Kevin Wolf wrote:
>> Am 01.07.2014 um 09:51 hat Ming Lei geschrieben:
>>> This patch introduces these two APIs so that following
>>> patches can support queuing I/O requests and submitting them
>>> at batch for impr
Am 01.07.2014 um 16:39 hat Ming Lei geschrieben:
> On Tue, Jul 1, 2014 at 9:31 PM, Ming Lei wrote:
> > On Tue, Jul 1, 2014 at 7:18 PM, Kevin Wolf wrote:
> >> Am 01.07.2014 um 09:51 hat Ming Lei geschrieben:
> >>> This patch introduces these two APIs so that following
> >>> patches can support que
Il 01/07/2014 17:21, Kevin Wolf ha scritto:
Does this bs->file forwarding work for more than the raw driver? For
example, if drv is an image format driver that needs to read some
metadata from the image before it can submit the payload, does this
still do what you were intending?
Sorry for not
On Wed, Jul 2, 2014 at 12:56 AM, Paolo Bonzini wrote:
> Il 01/07/2014 17:21, Kevin Wolf ha scritto:
>
> Does this bs->file forwarding work for more than the raw driver? For
> example, if drv is an image format driver that needs to read some
> metadata from the image before it can submi
On Wed, Jul 2, 2014 at 8:46 AM, Ming Lei wrote:
> On Wed, Jul 2, 2014 at 12:56 AM, Paolo Bonzini wrote:
>> Il 01/07/2014 17:21, Kevin Wolf ha scritto:
>>
>> Does this bs->file forwarding work for more than the raw driver? For
>> example, if drv is an image format driver that needs to read
Il 02/07/2014 02:46, Ming Lei ha scritto:
On Wed, Jul 2, 2014 at 12:56 AM, Paolo Bonzini wrote:
Il 01/07/2014 17:21, Kevin Wolf ha scritto:
Does this bs->file forwarding work for more than the raw driver? For
example, if drv is an image format driver that needs to read some
metadata from the i
Am 02.07.2014 um 10:18 hat Paolo Bonzini geschrieben:
> Il 02/07/2014 02:46, Ming Lei ha scritto:
> >On Wed, Jul 2, 2014 at 12:56 AM, Paolo Bonzini wrote:
> >>Il 01/07/2014 17:21, Kevin Wolf ha scritto:
> >>Does this bs->file forwarding work for more than the raw driver? For
> >>example, i
On Wed, Jul 2, 2014 at 4:18 PM, Paolo Bonzini wrote:
> Il 02/07/2014 02:46, Ming Lei ha scritto:
>
>> On Wed, Jul 2, 2014 at 12:56 AM, Paolo Bonzini
>> wrote:
>>>
>>> Il 01/07/2014 17:21, Kevin Wolf ha scritto:
>>>
>>> Does this bs->file forwarding work for more than the raw driver? For
>
Il 02/07/2014 10:38, Kevin Wolf ha scritto:
> On top of this, there _could_ be reasons for formats to implement
> plug/unplug themselves. They could coalesce metadata reads or
> copy-on-write operations, for example. This however is independent
> from the default behavior, which IMO is "pluggin
Il 02/07/2014 10:39, Ming Lei ha scritto:
Then start to read payload in original path, but no plug/unplug any
more. Also another request may follows, and another plug&unplug
comes too, which makes thing more complicated, so I suggest to
enable plug&unplug only for raw driver now.
That's just a
Am 02.07.2014 um 10:56 hat Paolo Bonzini geschrieben:
> Il 02/07/2014 10:39, Ming Lei ha scritto:
> >Then start to read payload in original path, but no plug/unplug any
> >more. Also another request may follows, and another plug&unplug
> >comes too, which makes thing more complicated, so I suggest
On Wed, Jul 2, 2014 at 4:56 PM, Paolo Bonzini wrote:
> Il 02/07/2014 10:39, Ming Lei ha scritto:
>
>> Then start to read payload in original path, but no plug/unplug any
>> more. Also another request may follows, and another plug&unplug
>> comes too, which makes thing more complicated, so I sugges
On Wed, Jul 2, 2014 at 5:12 PM, Kevin Wolf wrote:
> Am 02.07.2014 um 10:56 hat Paolo Bonzini geschrieben:
>> Il 02/07/2014 10:39, Ming Lei ha scritto:
>> >Then start to read payload in original path, but no plug/unplug any
>> >more. Also another request may follows, and another plug&unplug
>> >com
Am 02.07.2014 um 11:29 hat Ming Lei geschrieben:
> On Wed, Jul 2, 2014 at 5:12 PM, Kevin Wolf wrote:
> > Am 02.07.2014 um 10:56 hat Paolo Bonzini geschrieben:
> >> Il 02/07/2014 10:39, Ming Lei ha scritto:
> >> >Then start to read payload in original path, but no plug/unplug any
> >> >more. Also a
On Wed, Jul 2, 2014 at 5:49 PM, Kevin Wolf wrote:
> Am 02.07.2014 um 11:29 hat Ming Lei geschrieben:
>> On Wed, Jul 2, 2014 at 5:12 PM, Kevin Wolf wrote:
>> > Am 02.07.2014 um 10:56 hat Paolo Bonzini geschrieben:
>> >> Il 02/07/2014 10:39, Ming Lei ha scritto:
>> >> >Then start to read payload in
Il 02/07/2014 12:02, Ming Lei ha scritto:
Actually linux-aio can support to submit read/write to multi files, and
virtio-scsi does have the use case, so in future io queue should be
per aio-context as I posted 1st time. And I am wondering if multiwrite-like
APIs can fit in this situation.
Thou
On Wed, Jul 2, 2014 at 6:24 PM, Paolo Bonzini wrote:
> Il 02/07/2014 12:02, Ming Lei ha scritto:
>
Actually linux-aio can support to submit read/write to multi files, and
virtio-scsi does have the use case, so in future io queue should be
per aio-context as I posted 1st time. And I
20 matches
Mail list logo
