[CRIU] [PATCH 0/12] Speed up kdat checks

[Dmitry Safonov]

2017-04-25 18:15 GMT+03:00 Dmitry Safonov <0x7f454c46 at gmail.com>:
> 2017-04-25 17:13 GMT+03:00 Pavel Emelyanov <xemul at virtuozzo.com>:
>> On 04/25/2017 02:28 PM, Dmitry Safonov wrote:
>>> 2017-04-24 23:06 GMT+03:00 Pavel Emelyanov <xemul at virtuozzo.com>:
>>>> Hi
>>>>
>>>> I've been experimenting with criu restore times recently and the first
>>>> thing I've met was -- criu does a lot of slow checks on start in kerndat.c.
>>>>
>>>> Here's the proposal (not extremely elegant, though) how to fix this.
>>>>
>>>> We have a .config which is created empty on default built, but anyone can
>>>> put data into it and they will result in CONFIG_BLAH_BLAH propagates into
>>>> criu sources.
>>>>
>>>> The proposal is to introduce a set of config options for those kerndat.c
>>>> checks, that are "immutable" for a given node. Examples are in patches :)
>>>>
>>>> Also I've created the scripts/mklocalconfig.sh script that creates a
>>>> .config for local node. To determine some of the options the script runs
>>>> 'criu check --feature foo' command, which is ... not very nice, as one
>>>> need to build criu twice -- once to get "default" criu, then to get
>>>> configured criu.
>>>>
>>>> Suggestions on improving this are very welcome.
>>>
>>> So, it'll need recompiling criu according to each node?
>>
>> Yes :( And that's the thing I don't like myself.
>
> Ok, in my point of view user's convenience is worth of two-three
> syscalls per start :)
> But as default kdat way is still possible after patches, so anyway %)
>
>>> Just as a suggestion: have you considered making them
>>> not compile-time, but runtime in /etc/criu.conf or something?
>>
>> I did, but my plan was to save as much syscalls as possible and
>> opening reading and closing /etc/criu.conf is more VFS accesses than
>> I wanted.
>>
>>> One read and parsing config will not hurt much, as we'll
>>> need to do it anyway for other options.
>>> I don't mind, just node's config file looks like more convenient
>>> way to me.
>>
>> True, but from my perspective I'd better have non-criu binary that
>> would generate local config (if necessary) by using the same code as
>> criu does for auto-detection.
>
> Well, we could add a tool which in result produces a file with kerndat_s
> struct, then on c/r just mmap() it - munmap() will not be even necessary,
> as it'll go away on restorer blob enter.

Thinking about it some more - and I like it even more:
e.g,
criu check -o /run/criu.kdat
will create run-time kdat binary file.
On C/R we just mmap() it and skip kdat.
If it wasn't created with criu-check (say with rc during boot),
then the first invocation of criu does it.

And why I like it even more after some thinking: I thought that we
could put there some other properties preserved by kernel between
reboots: for example, parsed vdso symtable.

-- 
             Dmitry