[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <487FD251.9090204@cs.columbia.edu>
Date: Thu, 17 Jul 2008 19:14:25 -0400
From: Oren Laadan <orenl@...columbia.edu>
To: Dave Hansen <dave@...ux.vnet.ibm.com>
CC: "Eric W. Biederman" <ebiederm@...ssion.com>,
Kirill Korotaev <dev@...allels.com>,
containers@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, Nadia.Derbey@...l.net,
Andrew Morton <akpm@...ux-foundation.org>,
nick@...k-andrew.net, Alexey Dobriyan <adobriyan@...il.com>,
"Serge E. Hallyn" <serue@...ibm.com>
Subject: Re: Checkpoint/restart (was Re: [PATCH 0/4] - v2 - Object creation
with a specified id)
Dave Hansen wrote:
> On Wed, 2008-07-09 at 18:58 -0700, Eric W. Biederman wrote:
>> In the worst case today we can restore a checkpoint by replaying all of
>> the user space actions that took us to get there. That is a tedious
>> and slow approach.
>
> Yes, tedious and slow, *and* minimally invasive in the kernel. Once we
> have a tedious and slow process, we'll have some really good points when
"Replaying all of the user space actions that took us to get there" -
this task is not even always possible without deterministic log/replay
mechanism :(
Oren.
> we try to push the next set of patches to make it less slow and tedious.
> We'll be able to describe an _actual_ set of problems to our fellow
> kernel hackers.
>
> So, the checkpoint-as-a-corefile idea sounds good to me, but it
> definitely leaves a lot of questions about exactly how we'll need to do
> the restore.
>
> -- Dave
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists