Andrea Arcangeli wrote:
On Fri, Dec 12, 2008 at 08:35:57AM -0600, Anthony Liguori wrote:
I've been thinking about this, the problems I see are:
1) It's impossible to accept a file descriptor for a block device (possibly
not a problem)
What do you mean with accept? You mean to accept a tcp connection? How
would a block device fd be related to accept(2)?
I meant, if you wanted to pass a file descriptor as a raw device. So:
qemu -hda raw:fd=4
Or something like that. We don't support this today.
Now that linux-aio is out of the picture for quite a long time for us,
I guess it worth to wait preadv/pwritev and stick with that and
reconsider linux-aio after they fix it... Waiting Gerd to post a full
patch.
But it's your call... I'm fine either ways. Clearly the os missing
preadv/pwritev would need to be limited to 1 thread per fd (but 1
thread per fd kind of breaks with the current _global_ list so I guess
they'll be limited to just 1 thread otherwise it may be actually
simpler to just open the file multiple times than to have a per-fd
queue ;), not the end of the world for them.
I think bouncing the iov and just using pread/pwrite may be our best
bet. It means memory allocation but we can cap it. Since we're using
threads, we just can force a thread to sleep until memory becomes
available so it's actually pretty straight forward.
We can use libaio on older Linux's to simulate preadv/pwritev. Use the
proper syscalls on newer kernels, on BSDs, and bounce everything else.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
