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

[Marcelo Tosatti <mtosatti-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Mon, May 24, 2010 at 04:05:29PM +0900, Takuya Yoshikawa wrote:
> (2010/05/17 18:06), Takuya Yoshikawa wrote:
> >
> >>User allocated bitmaps have the advantage of reducing pinned memory.
> >>However we have plenty more pinned memory allocated in memory slots, so
> >>by itself, user allocated bitmaps don't justify this change.
> 
> Sorry for pinging several times.
> 
> >
> >In that sense, what do you think about the question I sent last week?
> >
> >=== REPOST 1 ===
> > >>
> > >> mark_page_dirty is called with the mmu_lock spinlock held in set_spte.
> > >> Must find a way to move it outside of the spinlock section.
> 
> I am now trying to do something to solve this spinlock problem. But the
> spinlock section looks too wide to solve with simple workaround.
> 
> >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? 

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.