"Dr. David Alan Gilbert" <dgilb...@redhat.com> wrote: > * Juan Quintela (quint...@redhat.com) wrote: >> Signed-off-by: Juan Quintela <quint...@redhat.com> > > Can you explain a bit more what's going on here?
Sorry. Until patch 20, we have what we had always have: pages that are sent through multifd (non zero pages). We are going to call it normal pages. So right now, we use the array of pages that we are passed in directly on the multifd send methods. But when we introduce zero pages handling around patch 20, we end having two types of pages sent through multifd: - normal pages (a.k.a. non-zero pages) - zero pages So the options are: - we rename the fields before we introduce the zero page code, and then we introduce the zero page code. - we rename at the same time that we introduce the zero page code. I decided to go with the 1st option. The other thing that we do here is that we introduce the normal array pages, so right now we do: for (i = 0; i < pages->num; i++) { p->narmal[p->normal_num] = pages->offset[i]; p->normal_num++: } Why? Because then patch 20 becomes: for (i = 0; i < pages->num; i++) { if (buffer_is_zero(page->offset[i])) { p->zerol[p->zero_num] = pages->offset[i]; p->zeronum++: } else { p->narmal[p->normal_num] = pages->offset[i]; p->normal_num++: } } i.e. don't have to touch the handling of normal pages at all, only this for loop. As an added benefit, after this patch, multifd methods don't need to know about the pages array, only about the params array (that will allow me to drop the locking earlier). I hope this helps. Later, Juan.