(2010/06/01 19:55), Marcelo Tosatti wrote:
Sorry but I have to say that mmu_lock spin_lock problem was completely
out of
my mind. Although I looked through the code, it seems not easy to move the
set_bit_user to outside of spinlock section without breaking the
semantics of
its protection.
So this may take some time to solve.
But personally, I want to do something for x86's "vmallc() every time"
problem
even though moving dirty bitmaps to user space cannot be achieved soon.
In that sense, do you mind if we do double buffering without moving
dirty bitmaps to
user space?
So I would be happy if you give me any comments about this kind of other
options.
What if you pin the bitmaps?
Yes, pinning bitmaps works. The small problem is that we need to hold
the dirty_bitmap_pages[] array for every slot, the size of this array
depends on the slot length, and of course pinning itself.
In the performance point of view, having double sized vmalloc'ed
area may be better.
The alternative to that is to move mark_page_dirty(gfn) before acquision
of mmu_lock, in the page fault paths. The downside of that is a
potentially (large?) number of false positives in the dirty bitmap.
Interesting, but probably dangerous.
From my experience, though this includes my personal view, removing vmalloc
currently used by x86 is the most simple and effective change.
So if you don't mind, I want to double the size of vmalloc'ed area for x86
without changing other parts.
==> if this one more bitmap is problematic, dirty logging itself would be
in danger of failure: we need to have the same size in the timing of
switch.
Make sense?
We can consider moving dirty bitmaps to user space later.
--
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
