* Re: [Qemu-devel] [RFC] parallelize migration_bitmap_sync() [not found] <512FE6C3.5030409@linux.vnet.ibm.com> @ 2013-03-01 9:34 ` Paolo Bonzini 2013-03-01 19:32 ` Michael R. Hines 2013-03-02 5:24 ` Michael R. Hines 0 siblings, 2 replies; 3+ messages in thread From: Paolo Bonzini @ 2013-03-01 9:34 UTC (permalink / raw) To: Michael R. Hines; +Cc: qemu-devel@nongnu.org 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 > support for cutting this time down much lower........by at least an > order of magnitude. > > Would anyone be opposed to me writing a patch that creates N threads and > dividing up the migration_bitmap_sync() function to have the dirty page > scanning run in parallel? Yes, that's a possibility. You can make a quick prototype using OpenMP. But Juan is working on making the dirty bitmap really a bitmap (not a "bytemap"). That should speed up migration_bitmap_sync by a factor of 64 (i.e. sizeof(long)*8). Paolo ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] [RFC] parallelize migration_bitmap_sync() 2013-03-01 9:34 ` [Qemu-devel] [RFC] parallelize migration_bitmap_sync() Paolo Bonzini @ 2013-03-01 19:32 ` Michael R. Hines 2013-03-02 5:24 ` Michael R. Hines 1 sibling, 0 replies; 3+ messages in thread From: Michael R. Hines @ 2013-03-01 19:32 UTC (permalink / raw) To: Paolo Bonzini; +Cc: qemu-devel@nongnu.org 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 ram >> virtual machine). >> Until new EPT processor versions come out in 2014, we need software >> support for cutting this time down much lower........by at least an >> order of magnitude. >> >> Would anyone be opposed to me writing a patch that creates N threads and >> dividing up the migration_bitmap_sync() function to have the dirty page >> scanning run in parallel? > Yes, that's a possibility. You can make a quick prototype using OpenMP. > > But Juan is working on making the dirty bitmap really a bitmap (not a > "bytemap"). That should speed up migration_bitmap_sync by a factor of > 64 (i.e. sizeof(long)*8). > > Paolo > ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] [RFC] parallelize migration_bitmap_sync() 2013-03-01 9:34 ` [Qemu-devel] [RFC] parallelize migration_bitmap_sync() Paolo Bonzini 2013-03-01 19:32 ` Michael R. Hines @ 2013-03-02 5:24 ` Michael R. Hines 1 sibling, 0 replies; 3+ messages in thread From: Michael R. Hines @ 2013-03-02 5:24 UTC (permalink / raw) Cc: Paolo Bonzini, qemu-devel@nongnu.org, quintela 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, >> >> 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 lower........by at least an >> order of magnitude. >> >> Would anyone be opposed to me writing a patch that creates N threads and >> dividing up the migration_bitmap_sync() function to have the dirty page >> scanning run in parallel? > Yes, that's a possibility. You can make a quick prototype using OpenMP. > > But Juan is working on making the dirty bitmap really a bitmap (not a > "bytemap"). That should speed up migration_bitmap_sync by a factor of > 64 (i.e. sizeof(long)*8). > > Paolo > ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-03-02 5:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <512FE6C3.5030409@linux.vnet.ibm.com>
2013-03-01 9:34 ` [Qemu-devel] [RFC] parallelize migration_bitmap_sync() Paolo Bonzini
2013-03-01 19:32 ` Michael R. Hines
2013-03-02 5:24 ` Michael R. Hines
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.