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

[Andrei Vagin]

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.

> 
> -- Pavel