From: Dave Hansen <haveblue@us.ibm.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>,
serue@us.ibm.com, linux-kernel@vger.kernel.org, dev@sw.ru,
devel@openvz.org, sam@vilain.net, ebiederm@xmission.com,
xemul@sw.ru, clg@fr.ibm.com
Subject: Re: [PATCH 0/9] namespaces: Introduction
Date: Fri, 19 May 2006 13:04:49 -0700 [thread overview]
Message-ID: <1148069089.6623.197.camel@localhost.localdomain> (raw)
In-Reply-To: <20060519081334.06ce452d.akpm@osdl.org>
On Fri, 2006-05-19 at 08:13 -0700, Andrew Morton wrote:
> snapshot/restart/migration worry me. If they require complete
> serialisation of complex kernel data structures then we have a problem,
> because it means that any time anyone changes such a structure they need to
> update (and test) the serialisation.
The idea of actually serializing kernel data structures keeps me up at
night. This is especially true when we already have some method of
exporting these structures to userspace.
Take VMAs, for example. Should we have a set of interfaces for saving
and restoring VMAs, or should we just make any program which is doing
checkpoint/restart use /proc/<pid>/maps on checkpoint and mmap() on
restore?
It, of course, isn't that simple. Any interface focused on VMAs inside
the kernel will have the serialization issues you describe. I think
this is such an approach:
http://git.openvz.org/?p=linux-2.6-openvz;a=blob;f=kernel/cpt/cpt_mm.c
http://git.openvz.org/?p=linux-2.6-openvz;a=blob;f=kernel/cpt/rst_mm.c
However, the proc-maps/mmap approach would require new interfaces to be
implemented. There are plenty of attributes not currently readily
visible to userspace like VM_NONLINEAR, or resources which are normally
inaccessible to userspace like deleted files. Those would need extended
user/kernel interfaces.
I know of at least one in-kernel commercial checkpoint/restart product
which was relatively well tested with "a certain large DB that uses
remap_file_pages()" that never even noticed that it completely missed
VM_NONLINEAR support until vm-savvy people saw the code. Scary.
-- Dave
next prev parent reply other threads:[~2006-05-19 20:06 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-18 15:47 Serge E. Hallyn
2006-05-18 15:48 ` [PATCH 1/9] namespaces: add nsproxy Serge E. Hallyn
2006-05-21 23:30 ` Sam Vilain
2006-05-21 23:38 ` Eric W. Biederman
2006-05-22 12:39 ` Serge E. Hallyn
2006-05-18 15:49 ` [PATCH 2/9] namespaces: incorporate fs namespace into nsproxy Serge E. Hallyn
2006-05-18 15:49 ` [PATCH 3/9] namespaces: utsname: introduce temporary helpers Serge E. Hallyn
2006-05-18 15:49 ` [PATCH 4/9] namespaces: utsname: switch to using uts namespaces Serge E. Hallyn
2006-05-19 0:02 ` Randy.Dunlap
2006-05-19 2:21 ` Serge E. Hallyn
2006-05-19 2:45 ` Randy.Dunlap
2006-05-19 3:12 ` Sam Vilain
2006-05-19 9:05 ` Eric W. Biederman
2006-05-19 17:39 ` Randy.Dunlap
2006-05-19 11:58 ` Eric W. Biederman
2006-05-22 19:43 ` Cedric Le Goater
2006-05-22 20:19 ` Randy.Dunlap
2006-05-22 0:19 ` Sam Vilain
2006-05-18 15:49 ` [PATCH 5/9] namespaces: utsname: use init_utsname when appropriate Serge E. Hallyn
2006-05-18 15:50 ` [PATCH 6/9] namespaces: utsname: implement utsname namespaces Serge E. Hallyn
2006-05-18 15:50 ` [PATCH 7/9] namespaces: utsname: sysctl hack Serge E. Hallyn
2006-05-18 15:50 ` [PATCH 8/9] namespaces: utsname: remove system_utsname Serge E. Hallyn
2006-05-18 23:03 ` Paul Mackerras
2006-05-18 23:04 ` Paul Mackerras
2006-05-18 15:51 ` [PATCH 9/9] namespaces: utsname: implement CLONE_NEWUTS flag Serge E. Hallyn
2006-05-18 17:34 ` [PATCH 0/9] namespaces: Introduction Andrew Morton
2006-05-18 19:23 ` John Kelly
2006-05-18 23:28 ` Sam Vilain
2006-05-18 23:43 ` Sam Vilain
2006-05-19 4:24 ` Paul Jackson
2006-05-19 9:23 ` Eric W. Biederman
2006-05-19 11:41 ` Eric W. Biederman
2006-05-19 17:52 ` Jeff Dike
2006-05-20 0:16 ` Sam Vilain
2006-05-19 12:42 ` Herbert Poetzl
2006-05-19 15:13 ` Andrew Morton
2006-05-19 16:27 ` Eric W. Biederman
2006-05-19 16:40 ` Andrew Morton
2006-05-19 17:15 ` Stephen Hemminger
2006-05-19 20:17 ` Dave Hansen
2006-05-19 20:52 ` Alexey Kuznetsov
2006-05-19 18:28 ` Hua Zhong
2006-05-19 19:38 ` Serge E. Hallyn
2006-05-19 19:45 ` John Kelly
2006-05-19 20:23 ` John Kelly
2006-05-19 20:04 ` Dave Hansen [this message]
2006-05-20 3:18 ` Eric W. Biederman
2006-05-21 0:48 ` Eric W. Biederman
2006-05-21 22:57 ` Pavel Machek
2006-05-21 23:18 ` Eric W. Biederman
2006-05-21 23:32 ` Herbert Poetzl
2006-05-22 16:54 ` Eric W. Biederman
2006-05-19 13:47 ` Andrey Savochkin
2006-05-19 15:25 ` Andrew Morton
2006-05-20 21:24 ` Herbert Poetzl
2006-05-22 17:23 ` Eric W. Biederman
2006-05-20 0:16 ` Sam Vilain
2006-05-19 8:50 ` Eric W. Biederman
2006-05-19 13:30 ` Serge E. Hallyn
2006-05-21 16:27 ` Serge E. Hallyn
2006-05-21 18:08 ` Eric W. Biederman
2006-05-22 12:10 ` Serge E. Hallyn
2006-05-22 16:44 ` Eric W. Biederman
2006-05-19 17:17 Al Boldi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1148069089.6623.197.camel@localhost.localdomain \
--to=haveblue@us.ibm.com \
--cc=akpm@osdl.org \
--cc=clg@fr.ibm.com \
--cc=dev@sw.ru \
--cc=devel@openvz.org \
--cc=ebiederm@xmission.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=sam@vilain.net \
--cc=serue@us.ibm.com \
--cc=xemul@sw.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome