[CRIU] Re: [PATCH] protobuf: Convert vma_entry to PB format v2
Cyrill Gorcunov
gorcunov at openvz.org
Thu Jul 19 04:16:47 EDT 2012
On Thu, Jul 19, 2012 at 12:05:25PM +0400, Pavel Emelyanov wrote:
> > @@ -149,10 +151,13 @@ static int read_and_open_vmas(int pid, struct list_head *vmas, int *nr_vmas)
> >
> > (*nr_vmas)++;
> > list_add_tail(&vma->list, vmas);
> > - ret = read_img_eof(fd, &vma->vma);
> > + ret = pb_read_eof(fd, &e, vma_entry);
> > if (ret <= 0)
> > break;
> >
> > + vma->vma = *e;
> > + vma_entry__free_unpacked(e, NULL);
> > +
>
> Why not store VmaEntry on vma_area?
Strictly speaking we can do that, but it will require a way more
intrusive patch (which I'm trying to escape at first). Pavel, lets
try to not optimize it at this stage, but map it 1:1 as it was earlier.
>
> > if (!(vma_entry_is(&vma->vma, VMA_AREA_REGULAR)))
> > continue;
> >
> > @@ -88,10 +90,17 @@ int prepare_shmem_pid(int pid)
> > }
> >
> > while (1) {
> > - ret = read_img_eof(fd, &vi);
> > + ret = pb_read_eof(fd, &tmp, vma_entry);
> > if (ret <= 0)
> > break;
> >
> > + /*
> > + * FIXME Optimize reading the messages which
> > + * have constant size.
> > + */
> > + vi = *tmp;
> > + vma_entry__free_unpacked(tmp, NULL);
> > +
>
> Huh? Why not just use tmp below?
It makes patch smaller and btw, it doesn't make _much_ sense
since both variables are referenced in code and you'll get
no speed up if tmp referenced here instead.
>
> > pr_info("vma 0x%lx 0x%lx\n", vi.start, vi.end);
> >
> > if (!vma_entry_is(&vi, VMA_ANON_SHARED))
>
Cyrill
More information about the CRIU
mailing list