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 708E7AED for ; Tue, 6 May 2014 13:23:19 +0000 (UTC) Received: from relay.parallels.com (relay.parallels.com [195.214.232.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 044B320114 for ; Tue, 6 May 2014 13:23:18 +0000 (UTC) Message-ID: <5368E242.7090001@parallels.com> Date: Tue, 6 May 2014 17:23:14 +0400 From: Pavel Emelyanov MIME-Version: 1.0 To: Jiri Kosina References: <53679974.60206@fb.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" 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 05/06/2014 02:08 AM, 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. It does takes a while, but not when there's a lot of memory mapped by tasks. This is what "preserving memory in place over kexec" is needed for -- we keep all tasks' memory in memory, thus avoiding long delays due to writing it on disk into images. Such thing performs poorly when there's a lot of _dirty_ memory hanging around. Thanks, Pavel