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

[Mike Rapoport]

On Wed, Apr 26, 2017 at 02:35:08AM +0300, Dmitry Safonov wrote:
> 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.

Another possibility is to use kernel post-install hooks of package manager
to recreate criu.kdat
 
> -- 
>              Dmitry

--
Sincerely yours,
Mike.