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

[Dmitry Safonov]

2017-04-25 23:37 GMT+03:00 Andrei Vagin <avagin at virtuozzo.com>:
> On Tue, Apr 25, 2017 at 11:17:27PM +0300, Pavel Emelyanov wrote:
>> 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?
>
> We can use /var/run or /dev/shm to save criu.kdat file and we can
> check that this file will be on tmpfs.

There are variants:
1. Rely it on package maintainer (to create criu.kdat in rc scripts during
boot or to place it on tmpfs). Still more flexible than compile-time
decision.
2. Place it on some reboot destroyed resource: shmem (shmget(), shmat() -
two syscalls), tmpfs (to check tmpfs some more syscalls)
3. Save generation time inside, check by current time - uptime, that is:
one sysinfo() syscall and gettimeofday() which is technically not a syscall
but vdso entry.
4. In my POV, type of check can be compile-time option between those
three, because it's just a realization's detail, not relaited to
node's env config.
So, it'll be up to pkg maintainer to provide systemd's service to remove/create
criu.kdat or to pay some syscalls in runtime for checking if criu.kdat
is obsolete.

-- 
             Dmitry