[CRIU] [PATCH 1/3] page-pipe: allow to handle pipes in batch mode
Andrew Vagin
avagin at parallels.com
Thu Jan 30 03:20:06 PST 2014
On Thu, Jan 30, 2014 at 03:07:12PM +0400, Pavel Emelyanov wrote:
> On 01/30/2014 12:21 PM, Andrey Wagin wrote:
> > 2014-01-30 Pavel Emelyanov <xemul at parallels.com>:
> >> On 01/30/2014 12:12 AM, Andrew Vagin wrote:
> >>> On Wed, Jan 29, 2014 at 05:13:23PM +0400, Pavel Emelyanov wrote:
> >>>> On 01/27/2014 06:22 PM, Andrey Vagin wrote:
> >>>>> The problem is that vmsplice() to a big pipe fails very often.
> >>>>>
> >>>>> The kernel allocates the linear chunk of memory for pipe buffer
> >>>>> descriptos, but big allocation in kernel can fail.
> >>>>>
> >>>>> So we need to restrict maximal capacity of pipes. But the number of
> >>>>> pipes is restricted too, so we need to dump memory in a batch mode.
> >>>>
> >>>> Batch mode means "several at once". Do you mean "... using one pipe"?
> >>>
> >>> I mean match mode "several at once" ;).
> >>
> >> Then current mode is batch also -- it pulls several pages into several
> >> pipes and dumps them all at once.
> >
> > The current mode does one iteration per process. The number of pipes
> > is not limited.
> >
> > Pavel, pls look at the next patch, it starts to use this code.
>
> I did. Let's try to follow the code with patches applied.
>
> __parasite_dump_pages_seized();
> `- create_page_pipe();
> | `- pp = xmalloc();
> | `- pp->pipe_nr = INT_MAX;
> | /* WTF? pp->nr_pipes initialization is removed */
> | page_pipe_grow();
Probably we don't need to call page_pipe_grow() here
> | `- pp->nr_pipes++; /* FTW? Why nr_pipes contains a garbage? */
> | open_pipe();
> | `- pp->pipe_nr--; /* For the record. INT_MAX - 1 is now here. */
> `- page_pipe_start_batching();
> | `- pp->pipe_nr = NR_PIPES_PER_BATCH; /* FTF? INT_MAX - 1 doesn't matter any longer?
And check here that we don't create any pipe yet
> | Any why it's NR_..._BATCH, while there's the whole 1 pipe in there? */
> `- generate_iovs()
> `- page_pipe_add_page()
> `- if (pp->pipe_nr == 0)
> | `- pp->batch_cb();
> | page_pipe_cleanup(); /* WTF? The pre-dump's pages get all flushed! */
> | `- page_pipe_close_buf(); /* WTF? Why do we start from the very beginning, there's
> | NR_..._BATCH plus 1 pipe in there already. */
> |
> `- page_pipe_grow();
> `- pp->nr_pipes++; /* WTF? This is increase-only counter. */
>
> I'm afraid that the WTF-per-KLOC value is too high to apply this set.
Don't worry, here is a bug, but even in this case this code is working
more stable than a previous one;). It creates NR_PIPES_PER_BATCH + 1
pipes instead of NR_PIPES_PER_BATCH and nothing more.
I'm going to resend this series. Thank you for the comments.
>
> Thanks,
> Pavel
More information about the CRIU
mailing list