[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