[CRIU] [PATCH 0/5] pipes: support for packetized mode (with O_DIRECT)

Pavel Emelyanov xemul at parallels.com
Mon Dec 21 02:33:11 PST 2015


On 12/18/2015 05:25 PM, Stanislav Kinsburskiy wrote:

>>> We can try to read many times with size, equal to pipe size.
>>> If we will be able to get more, than one buffer, then it's packetized pipe.
>>  From my perspective we don't have to distinguish packetized pipe from regular
>> when dumping queueu. Just write the data in the available chinks into the
>> pipe-date image and that's it.
> 
> Packetized pipe is expected to be read by chunks sizeof PIPE_BUF (== 
> PAGE_SIZE).
> In case of packetized pipe read will return only one buffer.
> In case of normal pipe it will return as many buffers, as fit into PIPE_BUF.
> 
>>
>>> If only one, then on restore:
>>> 1) If it's only read end without write, we don't care. We open a regular
>>> pipe and write this packet.
>>> 2) If it's a full pipe, then we a have a write end somewhere with
>>> O_DIRECT flag or without.
>>>
>>> Looks like this approach covers all the cases (except one very special,
>>> which we can not take into account).
>>>
>>> But it means, that we have to get rid of splice/vmsplice:
>>> 1) On dump, because we have to write all the packets individually.
>>> 2) On restore, because vmsplice doesn't work with packetized pipes.
>> BTW, I've glanced through the kernel and haven't found why splice doesn't
>> work for packetized pipes. Can you point out one?
> 
> Sure.
> 1) Splice pipe to image file on dump. In this case we loose all the 
> packets structure and having one single data chunk.

Why? Doesn't splice respect packetized buffers?

> 2) Vmsplice on restore. Packetized buffers have to be marked with 
> special flag, which vmsplice is not aware of. This leads to lsituation, 
> when all the packets they are returned as one single data chunk to a 
> pipe reader.

I see.

-- Pavel



More information about the CRIU mailing list