On Thu, Aug 11, 2016 at 3:11 PM, Li, Liang Z <liang.z...@intel.com> wrote: >> >> >> >> I might have missed something, could you tell me more? >> >> >> >> void bitmap_set(unsigned long *map, long start, long nr); I think the >> >> @start and @nr are both the number of the bits. >> >> >> >> thanks, >> >> Lai >> > >> > You are right, I have make a mistake by checking the code. Sorry for the >> noise. >> > >> > BTW. Is it possible to bypass the shared block in the >> 'ram_find_and_save_block'? >> > I mean no to check if a page is dirty for a shared block, it may make >> > things >> faster. >> >> Nice spotted. That would make things faster. But once there we could split >> the bitmap by ramblock, and the migration_dirty_pages also per block, that >> would make all the searchs faster, and adding/removing blocks of ram much >> easier. If we enter optimizing that function, we could really do much better >> that the "again" parameter that we have right now. >> >> Later, Juan.
This patch focuses on the core thing: adding the ability to bypass migrating the memory. I don't want to add further optimization for it now. I hope this patch merged solo and earlier. optimization patches can be sent after this patch accepted. > > Did some experiment with an 8GB VM. > Total time: 93ms > Setup: 70ms > Downtime: 6ms > > So most of the time spend on Setup stage, and most of the time spend on > setup stage is starting dirty page logging. > How about not start dirty page logging for shared blocks? then it's possible > to shorten the total time to about 30ms. bypass migrating the memory includes bypass copying&sending the memory (this patch, save seconds) bypass dirty page logging (save ten of milliseconds) bypass other thing?? 30ms is a huge part of the 130ms of the hyperhq cases. We definitely need it, I once tried it at the beginning, but it is a little complicated for me. So I focus the the major part now. Thanks, Lai > > Liang > > > > >