qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Replace posix-aio with custom thread pool


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] Replace posix-aio with custom thread pool
Date: Wed, 10 Dec 2008 11:21:58 -0600
User-agent: Thunderbird 2.0.0.17 (X11/20080925)

Andrea Arcangeli wrote:
On Tue, Dec 09, 2008 at 10:01:34AM -0600, Anthony Liguori wrote:
Yes, that's what I'm going to do before committing it.

I've been hacking on this too, just to push out a full tested patchset
without the _em badness... problem is if we use more than one thread,
there's a thread race between lseek and writev, pread/pwrite don't
have the issue as they store the pos on the kernel stack, and they
don't pass through the shared file->f_pos. We'd really need
preadv/pwritev...

To solve this in userland without kernel aio we'd need to open (not
just dup)

Why not just dup?  I've implemented this and it seems to work.

 the file in each thread, then the file->f_pos will become
thread local and we can cache the last lseek value and avoid the lseek
syscall for contiguous I/O. Or we need to reduce the number of threads
to 1 per fd (screwing seeking I/O). kernel aio wouldn't have this
trouble and a single fd/file would be enough, but that would only work
on linux.

I've also done a preadv/pwritev implementation in userspace using linux-aio.

My current plan is to finish the refactoring, then test out each implementation (dup() + lseek + readv vs. linux-aio) to see which one performs better. If they're equal, dup() wins out because it's more portable.

Regards,

Anthony Liguori

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to address@hidden
More majordomo info at  http://vger.kernel.org/majordomo-info.html





reply via email to

[Prev in Thread] Current Thread [Next in Thread]