[CRIU] CRIU: Is trying to dump and restore Chromium browser state hopeless? ("Unsupported mapping found")
Brinkmann, Harald
Harald.Brinkmann at bst-international.com
Fri May 12 02:39:59 PDT 2017
Hi Dmitry,
On Thu, 2017-05-11 at 22:48 +0300, Dmitry Safonov wrote:
> 2017-05-11 12:36 GMT+03:00 Brinkmann, Harald
> <Harald.Brinkmann at bst-international.com>:
> >
> > We want to save and restore a Chromium web browser process with a
> > complicated web page loaded. The hope is that restoring the browser
> > state is faster than reloading and reprocessing the web page.
> >
> > I can dump and restore a simple test process, so criu itself (commit
> > ed87c0f821a2) works.
> >
> > With Chromium everything looks fine until until I see that "Unsupported
> > mapping found" message in the criu dump log. I have modified criu to
> > print the vmflags and not to stop at the first "Unsupported mapping
> > found":
> >
> >
> > (00.892318) Dumping path for -3 fd via self 7 [/tmp/.org.chromium.Chromium.yo2UhN (deleted)]
> > (00.892343) Strip ' (deleted)' tag from './tmp/.org.chromium.Chromium.yo2UhN (deleted)'
> > (00.892359) Dumping ghost file for fd 7 id 0x20
> > (00.892376) mnt: Path `/tmp/.org.chromium.Chromium.yo2UhN' resolved to `./tmp' mountpoint
> > (00.892394) Dumping ghost file contents (id 0x5)
> > (00.913748) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms '
> > (00.913913) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
> > (00.913942) Warn (criu/proc_parse.c:638): Unsupported mapping found 000000005f4bd000-000000005f4dd000
> > (00.914113) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
> > (00.914141) Warn (criu/proc_parse.c:638): Unsupported mapping found 000000005f4dd000-000000005f4fd000
> >
> >
> > Eventually criu gives up with this message:
> >
> > (01.873078) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
> > (01.873127) Warn (criu/proc_parse.c:638): Unsupported mapping found 00000000632f0000-0000000063310000
> > (01.873371) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
> > (01.873421) Warn (criu/proc_parse.c:638): Unsupported mapping found 0000000063310000-0000000063330000
> > (01.873668) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
> > (01.874293) Warn (criu/proc_parse.c:638): Unsupported mapping found 0000000063330000-0000000063350000
> > (01.874504) Error (criu/proc_parse.c:568): Can't handle non-regular mapping on 3844's map 63350000
> > (01.874652) Error (criu/cr-dump.c:1223): Collect mappings (pid: 3844) failed with -1
> >
> >
> > Here are my questions:
> >
> > In addition to the pf and io flags that criu doesn't like, the dc, dd
> > and de flags are also set. While pf and io mean that a page cannot be
> > restored by criu, the others seem to indicate that it *should* not be
> > dumped in the first place. Could this be resolved by criu not dumping
> > and restoring these pages or would that just not work?
>
> No, that doesn't seem to be sane and shouldn't work.
> dc means that vma will not be copied on fork();
> dd - that pages will not be included in coredump;
> de just means that vma's size can't be changed.
> Regardless of those flags, application might need them and very likely
> will miss them after restoring.
>
> What I suspect - is that those mappings are related to gpu/drm/ion.
> And at this moment criu can't restore graphics context.
> Likely you can simply check if it's so by `cat /proc/<chromium_pid>/maps
> for those vmas.
Hmmm. This is criu's first error:
(00.935834) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms '
(00.936093) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
(00.936123) Error (criu/proc_parse.c:637): Unsupported mapping found 000000005f65e000-000000005f67e000
But cat /proc/484/smaps says:
an
5f65e000-5f67e000 rw-s 00000000 00:05 11582 /dev/zero (deleted)
Size: 128 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd wr sh mr mw me ms pf io dc de dd
There are many more of those, but in the end this happens:
(01.946575) Error (criu/proc_parse.c:637): Unsupported mapping found 0000000062b33000-0000000062b53000
(01.946708) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr sh mr mw me ms pf io dc de dd '
(01.946733) Error (criu/proc_parse.c:637): Unsupported mapping found 0000000062b53000-0000000062b73000
(01.946806) Warn (criu/proc_parse.c:108): parse_vmflags: 'mr mw me ac '
(01.946862) Warn (criu/proc_parse.c:108): parse_vmflags: 'rd wr mr mw me ac '
(01.946964) Error (criu/proc_parse.c:567): Can't handle non-regular mapping on 484's map 63373000
(01.947018) Error (criu/cr-dump.c:1223): Collect mappings (pid: 484) failed with -1
and that is:
63373000-6b373000 rw-s 00000000 00:06 1213 /dev/galcore
Size: 131072 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd wr sh mr mw me ms pf io dc de dd
FWIW we also have this:
72d37000-744f2000 rw-s 00000000 00:06 1511 /dev/fb0
Size: 24300 kB
Rss: 0 kB
Pss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 0 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
Shared_Hugetlb: 0 kB
Private_Hugetlb: 0 kB
Swap: 0 kB
SwapPss: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd wr sh mr mw me ms pf io de dd
> > We are building Chromium from source, so provided we know what we are
> > doing, modifying it is a theoretical possibility. E.g. Modifying the
> > memory mapping?
>
> If the conjecture about graphic mappings is right then you can hack around
> that by running chromium in vnc: https://criu.org/VNC
> But that will add performance degradation (how much? depends!), which
> you try to minimize, AFAICS.
Performance is already quite poor, so that isn't an option as you
already suspected.
> Another way would be to add C/R of gpu context..
> At this moment there was no progress made in that direction, AFAIK,
> by the following reasons:
> 1) It is a HUGE task.
> 2) We don't know any customer ready to pay for it.
> 3) No one in criu community does patches for that (likely by the same reasons).
>
> So, I might be wrong and these aren't gpu mappings - please, check it.
At least that is a clear and definite statement. At one time I was
hoping that we could get a restored Chromium to just redraw everything,
but from the sounds of it
> 1) It is a HUGE task.
and may not even work, either.
Thanks for your info.
Even though it will not solve my problem, is the "/dev/zero
(deleted)"-issue something you might be interested in or is that
behaviour as expected?
--
Kind regards
i.A. Harald Brinkmann
BST eltromat International GmbH
Werk Leopoldshöhe
Herforder Straße 249-251
D-33818 Leopoldshöhe
T: +49 (5208) 987-513
E: harald.brinkmann at bst-international.com
W: http://www.bst-eltromat.com
_______________________________________________________
Amtsgericht Bielefeld, HRB Nr. 30830
Geschäftsführer Kristian Jünke, Dr. Johann-Carsten Kipp, Dr. Gunter
Tautorus
Sitz der Gesellschaft: Bielefeld
Vertrauliche E-Mail von BST eltromat International GmbH
More information about the CRIU
mailing list