[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