On 02/24/2010 11:20 AM, Takuya Yoshikawa wrote:
Another issue I am thinking is the x86's bitmap allocation. Doing
vmalloc()
every time is not nice, though I know it's needed.
Right, that's why I want to move the allocation to userspace.
btw, one idea I had was to allocate the bitmap in userspace and let
the kernel set bits directly. This reduces the amount of unswappable
memory the kernel allocates and reduces copying.
A problem with this is that userspace cannot just clear the bits,
since the kernel has to write-protect the pages again. I don't know
how we can do this without copying the bitmap.
Yes, seems difficult.
Here's an idea: double buffering. Instead of copying the dirty log to
userspace, we switch the dirty log bitmap to another location
atomically. Then userspace can read the old bitmap.
Note the speed savings won't be huge, since the copying brings the
bitmap into cache, so the second pass is fairly fast. But if we combine
it with dropping the qemu byte-based dirty log, then we eliminate the
second pass as well.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
