From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 66210C02185 for ; Mon, 20 Jan 2025 07:54:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D7B5D6B0082; Mon, 20 Jan 2025 02:54:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D29876B0083; Mon, 20 Jan 2025 02:54:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C18366B0085; Mon, 20 Jan 2025 02:54:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id A5D5C6B0082 for ; Mon, 20 Jan 2025 02:54:31 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2599B4542B for ; Mon, 20 Jan 2025 07:54:31 +0000 (UTC) X-FDA: 83027067942.14.D9B85C9 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf02.hostedemail.com (Postfix) with ESMTP id 8DA7880007 for ; Mon, 20 Jan 2025 07:54:29 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tQMspNMi; spf=pass (imf02.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737359669; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=lsfpYg3DHRRAbRltg2X35bIX2MefRvdERabGM0E//Mo=; b=F0jQDl9feJa7xit7330JzWSTNY6MOtHnHfZqR9i9RbEt4ASQig+9h5WeAzzUUvVcUoY8/j X8zOlqF9H8qo7pUHfVeRJfFz4LnpRrB89xPcXqa9lCwJlaG6dTizSWVKMkx3WQCGuVt9Mc TYqNq8LiKuVSOajCZQXtu+i7hJifvSU= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=tQMspNMi; spf=pass (imf02.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737359669; a=rsa-sha256; cv=none; b=zZZ+89xn99PcRRcr0a6ddy97cQx+3jV2vNVyKNL5bN7ukubU0M0yXQbyQsjVheu54B2P+E T2HPB9PsqVDcuqZZdEZv0paCx7x9XB0Ja65GFdOCwxpakaCOS1HeqrGMKTKrEKr/WCoEWS i2ylJd9BMIk119yZHJ0F1C5mp2hQEdA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E9BB55C4740; Mon, 20 Jan 2025 07:53:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC1E5C4CEDD; Mon, 20 Jan 2025 07:54:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737359668; bh=PjNNto59/A9HfQVTtGpKMB1i8Ol7iaLwexYT4RGZKcY=; h=Date:From:To:Cc:Subject:From; b=tQMspNMiMOemJ+zoHtduacP45dVvPbvuo7z3A4OjtVbcsUlHbJeJz8LlncBocjESM SMRgzHVdO1FBnmZRrZswNHjwSZTK8fsbhAFj0CDOFCcsAAgC6qA9nUnmBrB+zLPqqB XjUvMWUbYRG5DLBgELSBOTYszKXZ4JLsGnxCzgwKSft1+gl0xQBW75yWSuQhFkQ0KS 9ULv1PVr98Py1bFurOEuTE3p01TuZm6nfBuSz9Sn40sf8j2rFEm9BGskSME1mxHw8F nwPn6EyX+XuyxDiTmuNtumip1WxUQDb1EJGf80A7vcleQNh3adiMhvmneB4DgcFcvZ eziOmdRIw9okA== Date: Mon, 20 Jan 2025 09:54:15 +0200 From: Mike Rapoport To: lsf-pc@lists.linux-foundation.org, Alexander Graf , "Gowans, James" Cc: linux-mm@kvack.org, David Rientjes , Pasha Tatashin Subject: [LSF/MM/BPF TOPIC] memory persistence over kexec Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 8DA7880007 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 6eucwt6fi8p5c8b8p49fjws6714kqcsk X-HE-Tag: 1737359669-900995 X-HE-Meta: U2FsdGVkX1/E7Dbf0wD3tAXsSrPrR5+HkBHTnp440wAhdOF2YGFLkrpHjQpc4K0tOOMN/QQXjvTqM5gLgjoH+1tjNSd5JWFWKgsGaNm4hXj0fmrCavdYGBKLSuN9csOF60kDsQ7hpIr0bLW+AiKgcVdqQ7NKSkc7JiQANWHcAg9PvzljohHpWGtA4TQXP2Xeu0mtVHVRi2f7SXKY9m5YGoCybgD+MenOEJls3bazlPYkpF0XO86lElN14CaqzcfcZFpdzHsS70Fsq37CiKO8TRI/RwgzZQ+BqBpXqSArO6PmmKAV+DL0MuGXIXu0PSs8XL9tJ2ahDeKhyAFQ1I+yvdBbmlZtH/o+AJ8vXdTv2bvNge+z8yBjOMDmdPIgx4zmpB6XYy2yQSgV7Fb++eB+rGkVBk+4B57Ny5au+J/ekqQULTl4mBJEtRz0/mY0A2xDK/e0dBc1u9kq/Ixh7DO86gcFHYDmfQIjKOVZg46ELXiVn0LlPNZyztZSp5YMmI6oTCfvoIu1FM9mvE8ZXFkOUevBfGM+k+7Ps0mTGxay4sZTKWd9xfvUozoXQLJbt0crldpZlseXCDTPZ549PDJ4e/vBBHnH/pTVoHEUYOLCStW9s7h+nnKqdu5fZba/Ya3364cn2nS87FI83/GhbKTn0lJZR/5ZKhLqfPRi6MJrIeKBwayD70JgOgX3evB9uB/gs1cEDceNC38nssw/KFzYxarz3jS5k9gaby8JLCg7R7JdViZptTKuC9KAoczgnQwbEWQ4xO4zTXF4BASDQju/220nWEvaXAQHjNJHrtYCaD6BvJtsg3qcG8IuxFBguDKaF2m4rPOp2TNliOjvXcbRprTuE+Y6L3HmgrZ5mJmDD4vC5T9YJ0MQFMNFUhUQr/b1Q/a6zo72EgGNvbkopRdxpunXDIRTZAUBX7Lj7Jf8vKlUNINZZOyPxDZm1KA+0702SeksiUQh0xSge6MJhQ4 ytgStI/a paLi3w7euKRHeZGLgCse0AtBPhwngjKxqv7LNWrW/BSHuJKeDfLuvhRhTg9xNY3m4SzntbxDS+7k3Ry7BcrxNn50Trmo92c4MRA0WtEP5xGSdQyjbpZ2xmyJXQMI313hysQkDKUqYdXaGC8/JFgAqWrXTXCSDZVaFEpuI9klYibxh5GQ0YaYnEfwdvPhMWpnxgjwyLqJhFBgvGnasZYChZeCvQM/mBKcQhsWKNCvdIHLM1zFzlI48kzfgZ2GJRFRxMPOVi79Plfk4yME2lFTH5QMnZAen5rTe/493LPnCu0FqqoE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi, I'd like to discuss memory persistence across kexec. Currently there is ongoing work on Kexec HandOver (KHO) [1] that allows serialization and deserialization of kernel data as well as preserving arbitrary memory ranges across kexec. In addition, KHO keeps a physically contiguous memory regions that are guaranteed to not have any memory that KHO would preserve, but still can be used by the system. The kexeced kernel bootstraps itself using those regions and sets all handed over memory as in use. KHO users then can recover their state from the preserved data. This includes memory reservations, where the user can either discard or claim reservations. KHO can be used as the base layer for implementation of persistence-aware memory allocator and persistent in-memory filesystem. Aside from status update on KHO progress there are a few topics that I would like to discuss: * Is it feasible and desirable to enable KHO support in tmpfs and hugetlbfs? * Or is it better to implement yet another in-memory filesystem dedicated for persistence? * What is the best way to ensure that the memory we want to persist is not scattered all over the place? [1] https://lore.kernel.org/all/20240117144704.602-1-graf@amazon.com/ -- Sincerely yours, Mike.