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. -- To unsubscribe from this list: send the line "unsubscribe kvm-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
