| Message ID | 20191001100122.17730-3-richardw.yang@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | migration/postcopy: cleanup related to postcopy | expand |
* Wei Yang (richardw.yang@linux.intel.com) wrote: > postcopy_ram_incoming_cleanup() does cleanup for > postcopy_ram_incoming_setup(), while the setup happens only after > migration enters LISTEN state. > > This means there is nothing to cleanup when migration is still ADVISE > state. > > Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> > --- > migration/migration.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/migration/migration.c b/migration/migration.c > index 5f7e4d15e9..34d5e66f06 100644 > --- a/migration/migration.c > +++ b/migration/migration.c > @@ -461,7 +461,6 @@ static void process_incoming_migration_co(void *opaque) > * but managed to complete within the precopy period, we can use > * the normal exit. > */ > - postcopy_ram_incoming_cleanup(mis); > } else if (ret >= 0) { > /* > * Postcopy was started, cleanup should happen at the end of the I think that misses the cleanup of mlock that corresponds to the munlockall in postcopy_ram_supported_by_host - that's called very early on; I think in the advise stage. Dave > -- > 2.17.1 > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On Tue, Oct 08, 2019 at 05:02:02PM +0100, Dr. David Alan Gilbert wrote: >* Wei Yang (richardw.yang@linux.intel.com) wrote: >> postcopy_ram_incoming_cleanup() does cleanup for >> postcopy_ram_incoming_setup(), while the setup happens only after >> migration enters LISTEN state. >> >> This means there is nothing to cleanup when migration is still ADVISE >> state. >> >> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> >> --- >> migration/migration.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/migration/migration.c b/migration/migration.c >> index 5f7e4d15e9..34d5e66f06 100644 >> --- a/migration/migration.c >> +++ b/migration/migration.c >> @@ -461,7 +461,6 @@ static void process_incoming_migration_co(void *opaque) >> * but managed to complete within the precopy period, we can use >> * the normal exit. >> */ >> - postcopy_ram_incoming_cleanup(mis); >> } else if (ret >= 0) { >> /* >> * Postcopy was started, cleanup should happen at the end of the > >I think that misses the cleanup of mlock that corresponds to the >munlockall in postcopy_ram_supported_by_host - that's called very early >on; I think in the advise stage. > Thanks you are right. BTW, do we need to check enable_mlock when calling munlockall() in postcopy_ram_supported_by_host() ? >Dave > >> -- >> 2.17.1 >> >-- >Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
* Wei Yang (richardw.yang@linux.intel.com) wrote: > On Tue, Oct 08, 2019 at 05:02:02PM +0100, Dr. David Alan Gilbert wrote: > >* Wei Yang (richardw.yang@linux.intel.com) wrote: > >> postcopy_ram_incoming_cleanup() does cleanup for > >> postcopy_ram_incoming_setup(), while the setup happens only after > >> migration enters LISTEN state. > >> > >> This means there is nothing to cleanup when migration is still ADVISE > >> state. > >> > >> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> > >> --- > >> migration/migration.c | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/migration/migration.c b/migration/migration.c > >> index 5f7e4d15e9..34d5e66f06 100644 > >> --- a/migration/migration.c > >> +++ b/migration/migration.c > >> @@ -461,7 +461,6 @@ static void process_incoming_migration_co(void *opaque) > >> * but managed to complete within the precopy period, we can use > >> * the normal exit. > >> */ > >> - postcopy_ram_incoming_cleanup(mis); > >> } else if (ret >= 0) { > >> /* > >> * Postcopy was started, cleanup should happen at the end of the > > > >I think that misses the cleanup of mlock that corresponds to the > >munlockall in postcopy_ram_supported_by_host - that's called very early > >on; I think in the advise stage. > > > > Thanks you are right. > > BTW, do we need to check enable_mlock when calling munlockall() in > postcopy_ram_supported_by_host() ? I don't think so; it does an extra munlock in that case when nothing should be locked anyway, no harm. Dave > >Dave > > > >> -- > >> 2.17.1 > >> > >-- > >Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > -- > Wei Yang > Help you, Help me -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
diff --git a/migration/migration.c b/migration/migration.c index 5f7e4d15e9..34d5e66f06 100644 --- a/migration/migration.c +++ b/migration/migration.c @@ -461,7 +461,6 @@ static void process_incoming_migration_co(void *opaque) * but managed to complete within the precopy period, we can use * the normal exit. */ - postcopy_ram_incoming_cleanup(mis); } else if (ret >= 0) { /* * Postcopy was started, cleanup should happen at the end of the
postcopy_ram_incoming_cleanup() does cleanup for postcopy_ram_incoming_setup(), while the setup happens only after migration enters LISTEN state. This means there is nothing to cleanup when migration is still ADVISE state. Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> --- migration/migration.c | 1 - 1 file changed, 1 deletion(-)