* Juan Quintela (quint...@redhat.com) wrote:
> "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.
OK, so the code is OK, but it needs a commit message that explains all
that a bit more concisely.
Dave
> Later, Juan.
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
