Re: Any comments? Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space

[Marcelo Tosatti <mtosatti@redhat.com>]

On Tue, Jun 01, 2010 at 09:05:38PM +0900, Takuya Yoshikawa wrote:
> (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?

That seems the most sensible approach.

> 
> We can consider moving dirty bitmaps to user space later.