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

[Andrei Vagin]

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.

> >
> > 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.
> 
> Thinking about it some more - and I like it even more:
> e.g,
> criu check -o /run/criu.kdat
> will create run-time kdat binary file.
> On C/R we just mmap() it and skip kdat.
> If it wasn't created with criu-check (say with rc during boot),
> then the first invocation of criu does it.
> 
> And why I like it even more after some thinking: I thought that we
> could put there some other properties preserved by kernel between
> reboots: for example, parsed vdso symtable.
> 
> -- 
>              Dmitry
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu