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

[Dmitry Safonov]

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.

-- 
             Dmitry