Ok, thanks, I'll think about it.
On 27.01.2016 15:42, Dr. David Alan Gilbert wrote:
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
Hello, Dr. Gilbert!
Hi Vladimir,
As I understand this is not a complete realization of post-copy stage of
migration, but only realization of ra
* Vladimir Sementsov-Ogievskiy (vsement...@virtuozzo.com) wrote:
> Hello, Dr. Gilbert!
Hi Vladimir,
> As I understand this is not a complete realization of post-copy stage of
> migration, but only realization of ram post-copy.
Yes, that's correct; RAM was the only one we'd had much interest in;
Hello, Dr. Gilbert!
As I understand this is not a complete realization of post-copy stage of
migration, but only realization of ram post-copy.. I need to implement
post-copy migration of block-dirty-bitmaps. And it should work
with/without ram post-copy. Did you plan a possibility of post-copy
* Juan Quintela (quint...@redhat.com) wrote:
> "Dr. David Alan Gilbert (git)" wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > This is the 9th cut of my version of postcopy.
> >
> > The userfaultfd linux kernel code is now in the upstream kernel
> > tree, and so 4.3 can be used without modific
"Dr. David Alan Gilbert (git)" wrote:
> From: "Dr. David Alan Gilbert"
>
> This is the 9th cut of my version of postcopy.
>
> The userfaultfd linux kernel code is now in the upstream kernel
> tree, and so 4.3 can be used without modification.
>
> This qemu series can be found at:
> https://gith
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> On Mon, Nov 09, 2015 at 11:03:02AM +, Dr. David Alan Gilbert wrote:
> >
> >
> > Oh, I think I see it; the following is untested, I'll grab a machine to
> > try it on but it will take a little while:
> >
> > diff --git a/migration/ram.c b/
On Mon, Nov 09, 2015 at 11:03:02AM +, Dr. David Alan Gilbert wrote:
>
>
> Oh, I think I see it; the following is untested, I'll grab a machine to
> try it on but it will take a little while:
>
> diff --git a/migration/ram.c b/migration/ram.c
> index 62cf42b..e6db965 100644
> --- a/migration/
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> On Mon, Nov 09, 2015 at 09:08:33AM +, Dr. David Alan Gilbert wrote:
> > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> > > On Fri, Nov 06, 2015 at 03:48:11PM +, Dr. David Alan Gilbert wrote:
> > > > * Bharata B Rao (bhar...@linux.
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> On Fri, Nov 06, 2015 at 03:48:11PM +, Dr. David Alan Gilbert wrote:
> > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> >
> > > > Where we have iterable, but non-postcopiable devices (e.g. htab
> > > > or block migration), complete th
On 09/11/2015 05:13, David Gibson wrote:
> Which makes me think it's a bit odd that we're not already getting
> most of the htab data across during the precopy phase. Don't we
> already delay entering the postcopy phase until precopy is
> "complete" in the sense that the remaining non-postcopi
On Fri, Nov 06, 2015 at 12:22:23PM +, Dr. David Alan Gilbert wrote:
> * Bharata B Rao (bharata@gmail.com) wrote:
> > On Fri, Nov 6, 2015 at 2:39 PM, Dr. David Alan Gilbert
> > wrote:
> > > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> > >> On Thu, Nov 05, 2015 at 06:10:27PM +,
On Fri, Nov 06, 2015 at 03:48:11PM +, Dr. David Alan Gilbert wrote:
> * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
>
> > > Where we have iterable, but non-postcopiable devices (e.g. htab
> > > or block migration), complete them before forming the 'package'
> > > but with the CPUs stoppe
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> > Where we have iterable, but non-postcopiable devices (e.g. htab
> > or block migration), complete them before forming the 'package'
> > but with the CPUs stopped. This stops them filling up the package.
>
> That helps and the migration suce
On Fri, Nov 06, 2015 at 01:43:42PM +, Dr. David Alan Gilbert wrote:
> * Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> > * Bharata B Rao (bharata@gmail.com) wrote:
> > > On Fri, Nov 6, 2015 at 2:39 PM, Dr. David Alan Gilbert
> > > wrote:
> > > > * Bharata B Rao (bhar...@linux.vnet.i
* Dr. David Alan Gilbert (dgilb...@redhat.com) wrote:
> * Bharata B Rao (bharata@gmail.com) wrote:
> > On Fri, Nov 6, 2015 at 2:39 PM, Dr. David Alan Gilbert
> > wrote:
> > > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> > >> On Thu, Nov 05, 2015 at 06:10:27PM +, Dr. David Alan Gil
* Bharata B Rao (bharata@gmail.com) wrote:
> On Fri, Nov 6, 2015 at 2:39 PM, Dr. David Alan Gilbert
> wrote:
> > * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> >> On Thu, Nov 05, 2015 at 06:10:27PM +, Dr. David Alan Gilbert (git)
> >> wrote:
> >> > From: "Dr. David Alan Gilbert"
>
On Fri, Nov 6, 2015 at 2:39 PM, Dr. David Alan Gilbert
wrote:
> * Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
>> On Thu, Nov 05, 2015 at 06:10:27PM +, Dr. David Alan Gilbert (git) wrote:
>> > From: "Dr. David Alan Gilbert"
>> >
>> > This is the 9th cut of my version of postcopy.
>> >
* Bharata B Rao (bhar...@linux.vnet.ibm.com) wrote:
> On Thu, Nov 05, 2015 at 06:10:27PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > This is the 9th cut of my version of postcopy.
> >
> > The userfaultfd linux kernel code is now in the upstream kernel
On Thu, Nov 05, 2015 at 06:10:27PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> This is the 9th cut of my version of postcopy.
>
> The userfaultfd linux kernel code is now in the upstream kernel
> tree, and so 4.3 can be used without modification.
>
> This q
19 matches
Mail list logo
