From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id 485F0AF3 for ; Tue, 6 May 2014 13:17:54 +0000 (UTC) Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [66.63.167.143]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0F7161FDEC for ; Tue, 6 May 2014 13:17:54 +0000 (UTC) Message-ID: <1399382270.2237.9.camel@dabdike.int.hansenpartnership.com> From: James Bottomley To: Jiri Kosina Date: Tue, 06 May 2014 06:17:50 -0700 In-Reply-To: References: <53679974.60206@fb.com> Content-Type: text/plain; charset="ISO-8859-15" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 2014-05-06 at 00:08 +0200, Jiri Kosina wrote: > On Mon, 5 May 2014, Andy Lutomirski wrote: > > > > Tons of interest in this topic here, mostly for the in-memory database > > > workloads. > > > > Would in-memory databases be happier if there were a way to kexec > > without losing your data? > > Well, that's basicaly what criu-based aproach is doing. With the drawback > that dumping during checkpointing can take a while for large tasks (such > as in-memory databases) I guess. Well, no that's not correct. You've seen the patches for the pramfs capsule which is not upstream (and probably won't be now we're looking at doing something similar with splice). The idea is basically we do a zero copy checkpoint by passing pages into some type of capsule which survives the kexec. The restore then does a zero copy pull pages out of the capsule and reattach them, so most of the time is really just the kexec of the new kernel. James