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

[Pavel Emelyanov]

On 04/25/2017 10:43 PM, Andrei Vagin wrote:
> On Tue, Apr 25, 2017 at 09:07:47PM +0300, Dmitry Safonov wrote:
>> 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.
> 
> I don't like an idea  when we need to recompile criu to get support for
> features. I vote for Dima's idea with a state file. open(), map() will
> not affect performance significantly.

OK. Let's imagine we've made it this way, then someone created criu.kdat
file, then upgraded the kernel and rebooted. How do we know that the
criu.kdat is obsolete and need to be re-generated?

-- Pavel