"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.
