|
|
Samuel Thibault wrote:
Ah, I thought you understood that the posix driver has the same kind of
limitation
It's not the same limitation. The posix driver has no limits on DMA
size, it will happily transfer a gigabyte of data if you ask it to.
(and qemu is actually _bugged_ in that regard).
It has a bug in that it does not correctly interpret the return value of
pread()/pwrite(). It's a minor bug since no system supported by qemu
will actually return a short read or write (I think) and in that we
hope disk errors are rare. Nevertheless it should be fixed (it's an
easy fix too). However implementing DMA limits like you propose
(IDE_DMA_BUF_SECTORS) will not fix the bug, only reduce performance.
I'm here just pointing out that the problem is not
_only_ in the xen-specific driver, but also in the posix driver, on any
OS that doesn't necessarily do all the work the caller asked for (which
is _allowed_ by POSIX).
But that's not limited DMA (or at least, not limited up-front). And
it's easily corrected, place a while loop around preadv/pwritev, no need
to split a request a priori somewhere up the stack.
Sure, and I could do the same in the block-vbd driver, thus then my
original remark "it should be centralized in the block layer instead of
placing the burden on all block format drivers". Just to make sure: I'm
_not_ saying that should be done in the DMA code. I said it should be
done in the block layer, shared by all block drivers.
A generic fix will have to issue a new aio request. block-raw-posix
need not do that, just a while loop.
And it wouldn't be right for block-vbd - you should split your requests
as late as possible, IMO.
Why making it "late"? Exposing the lower limits to let upper layers
decide how they should manage fragmentation usually gets better
performance. (Note that in my case there is no system involved, so it's
really _not_ costly to do the fragmentation on the qemu side).
If ring entries can be more than a page (if the request is contiguous),
then the limit can be expanded. In other words, it's a worst-case
limit, not a hard limit. Exposing the worst case limit will lead to
pessimistic choices.
That's how virtio-blk works, don't know about xen vbd (might not work
due to the need to transfer grants?)
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
|
|