Re: [Qemu-devel] [RFC] parallelize migration_bitmap_sync()

2013-03-01 Thread Michael R. Hines
Juan, Can I try this patch that Paolo mentioned? Does it go directly from GET_LOG_DIRTY => migration_bitmap? Or is there still an intermediate sync in your patch? Thanks, - Michael On 03/01/2013 04:34 AM, Paolo Bonzini wrote: Il 01/03/2013 00:22, Michael R. Hines ha scritto:te Hi, Currentl

Re: [Qemu-devel] [RFC] parallelize migration_bitmap_sync()

2013-03-01 Thread Michael R. Hines
Oh, that's fantastic - thanks for the response. - Michael On 03/01/2013 04:34 AM, Paolo Bonzini wrote: Il 01/03/2013 00:22, Michael R. Hines ha scritto:te Hi, Currently migration_bitmap_sync() is very expensive: on the order of 15-20 milliseconds by my count using timestamps (for a simple 2GB

Re: [Qemu-devel] [RFC] parallelize migration_bitmap_sync()

2013-03-01 Thread Paolo Bonzini
Il 01/03/2013 00:22, Michael R. Hines ha scritto:te > Hi, > > Currently migration_bitmap_sync() is very expensive: on the order of > 15-20 milliseconds by my count using timestamps (for a simple 2GB ram > virtual machine). > Until new EPT processor versions come out in 2014, we need software > sup

[Qemu-devel] [RFC] parallelize migration_bitmap_sync()

2013-02-28 Thread Michael R. Hines
Hi, Currently migration_bitmap_sync() is very expensive: on the order of 15-20 milliseconds by my count using timestamps (for a simple 2GB ram virtual machine). Until new EPT processor versions come out in 2014, we need software support for cutting this time down much lowerby at least