On Tue, Jul 24, 2018 at 12:42:06PM +0100, Dr. David Alan Gilbert wrote: > * Peter Xu (pet...@redhat.com) wrote: > > On Tue, Jul 24, 2018 at 11:25:24AM +0200, Juan Quintela wrote: > > > Peter Xu <pet...@redhat.com> wrote: > > > > The release-ram capability will run some extra code for postcopy to > > > > release used ram right away, let's just turn that on for the postcopy > > > > unix test always to torture that code path too to make sure release-ram > > > > feature won't break again. The recovery test needs to turn that off > > > > since release-ram cannot coop with that. > > > > > > > > Signed-off-by: Peter Xu <pet...@redhat.com> > > > > > > Reviewed-by: Juan Quintela <quint...@redhat.com> > > > > Thanks. > > > > > > > > But I think that the proper thing to do here is to have two tests. One > > > for postcopy and another for postcopy + release-ram. > > > > Yeah I thought about it too, but I am not sure whether it'll worth it > > to have a separate test for the release-ram feature (basically that's > > some extra seconds for every unit test, even on relatively fast CPUs). > > I did it this way since IMHO release-ram is mostly adding extra code > > path to the postcopy logic, hence we should not miss much (or any) of > > the old test path. Ideally we should still cover all the postcopy > > code path that we want to test. > > It's worth being a bit careful, since I'm not sure if release-ram has > ever been tested on hosts with larger page size; my suspicion is you > might get a spew of errors on Power.
Oh I hope not. If it happens, please feel free to drop this last patch for 3.0. Or I can provide a x86-only version if preferred. Regards, -- Peter Xu
