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 8F6C6C02188 for ; Mon, 27 Jan 2025 16:12:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0586628017C; Mon, 27 Jan 2025 11:12:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 007F028017A; Mon, 27 Jan 2025 11:12:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E11B228017C; Mon, 27 Jan 2025 11:12:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C34F728017A for ; Mon, 27 Jan 2025 11:12:49 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7E7A21C7183 for ; Mon, 27 Jan 2025 16:12:49 +0000 (UTC) X-FDA: 83053725258.04.88CCD15 Received: from smtp-fw-6002.amazon.com (smtp-fw-6002.amazon.com [52.95.49.90]) by imf15.hostedemail.com (Postfix) with ESMTP id 2B6DDA001A for ; Mon, 27 Jan 2025 16:12:46 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b="U/hyFxdx"; spf=pass (imf15.hostedemail.com: domain of "prvs=1155a3140=graf@amazon.de" designates 52.95.49.90 as permitted sender) smtp.mailfrom="prvs=1155a3140=graf@amazon.de"; dmarc=pass (policy=quarantine) header.from=amazon.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737994367; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=mZ9QeePiwXu36SStcJ29QbMXFjd5SFxGF50KS1mTIeA=; b=8YJZWAvrPStuwNdoEHwNqOgLJ+Rz5mT2UTFzfldA/nsFFWY3soDk8Na6Rrd7u3TY8Q/wsA PGhhaYFLRpirvr49V1IDrDxXEJ5xNErEyx/Q9Eh610zQWUCoiVM7XkbN8Hrb5I9jJlFe5S JWKmF2tjqD8+WF2XTsBmiCd8Sf1TarY= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=amazon.com header.s=amazon201209 header.b="U/hyFxdx"; spf=pass (imf15.hostedemail.com: domain of "prvs=1155a3140=graf@amazon.de" designates 52.95.49.90 as permitted sender) smtp.mailfrom="prvs=1155a3140=graf@amazon.de"; dmarc=pass (policy=quarantine) header.from=amazon.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737994367; a=rsa-sha256; cv=none; b=qPMtcD9G4jopjtyhWSrg+bDntX6NvMqmKFyRcKOkAoj2NfCBi2e4HTyA7R4MeaYnZUt6DZ ISd0tY+LMsvnHupESqCTBnh8EQAFcJlzffcUcVshky49KVFiH3IqDSIw1YZLAzjuoUuPnU Jswvvr36t+AEc/V0pr/b2NtkOdbyYHo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1737994368; x=1769530368; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=mZ9QeePiwXu36SStcJ29QbMXFjd5SFxGF50KS1mTIeA=; b=U/hyFxdxPei9oEPqI/cO1PrxzGPNj6WsdLJzW1RY45qq6DJczOw+/mip eHy4tQCD/vHkT2P9TpGcW4jHJzIN2kkcPYONDSsbBtd18znUiSvHNzmIU qZXUxQ8RhAZJJpWN+M9t9Gz426uIDcPJ/4ixFnrUWxyFT9Jhd0XIhUv/9 w=; X-IronPort-AV: E=Sophos;i="6.13,238,1732579200"; d="scan'208";a="467185349" Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.43.8.6]) by smtp-border-fw-6002.iad6.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Jan 2025 16:12:45 +0000 Received: from EX19MTAUWA002.ant.amazon.com [10.0.38.20:3141] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.42.178:2525] with esmtp (Farcaster) id bb1555f3-f7d9-4659-a207-9ffbbf3647ed; Mon, 27 Jan 2025 16:12:43 +0000 (UTC) X-Farcaster-Flow-ID: bb1555f3-f7d9-4659-a207-9ffbbf3647ed Received: from EX19D020UWC004.ant.amazon.com (10.13.138.149) by EX19MTAUWA002.ant.amazon.com (10.250.64.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.39; Mon, 27 Jan 2025 16:12:43 +0000 Received: from [0.0.0.0] (10.253.83.51) by EX19D020UWC004.ant.amazon.com (10.13.138.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.39; Mon, 27 Jan 2025 16:12:40 +0000 Message-ID: Date: Mon, 27 Jan 2025 08:12:37 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [LSF/MM/BPF TOPIC] memory persistence over kexec To: Jason Gunthorpe CC: Pasha Tatashin , Mike Rapoport , David Rientjes , , "Gowans, James" , References: <20250120141427.GK674319@ziepe.ca> <20250126200404.GA1103620@ziepe.ca> <54945e03-c437-48b4-b739-4e8ac822c1fc@amazon.com> <20250127131512.GC1103620@ziepe.ca> Content-Language: en-US From: Alexander Graf In-Reply-To: <20250127131512.GC1103620@ziepe.ca> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.253.83.51] X-ClientProxiedBy: EX19D033UWC004.ant.amazon.com (10.13.139.225) To EX19D020UWC004.ant.amazon.com (10.13.138.149) X-Rspamd-Queue-Id: 2B6DDA001A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: eib8uywc6fj8axgnbqo1kz34qybgfioo X-HE-Tag: 1737994366-962071 X-HE-Meta: U2FsdGVkX1+W+Gi2lBB0224749uvKdfFoLgDAj+E7lV11UoeRxcnTw6AaFzOSAzzHI7zsC5EFqUR4bxOYGBfOLa3hSH9HhDKgUvV69UR1j8iZjF7rU+084BloRIu6wu6xhHznecOUghYkik/ZkrYBlyP/OBMAPX2+ghFkiHFX/M89ecARmUnHkTPG/nQaXGtO7m6ygGhey0pioo1edFGdpL7Txu4xTLd/D3qyRL8Ok0tn+JbfqkaR3m7+TrxL0VOD2IXun4afPh+DEm7LsilVSoBH1Iw9Z6lLQnNK1LuR17Gwf0tk4IoE/Ou3ObMfyGIrVZx9+ccQj+12ey86svrGM62vQPP43wzjcqSWVJatKHD0m/ZmdIvMZb+QDQ33yJHj1YbZQByr/MXw4FRNv8GHhe0F/kDBfCCdVXkAf6THuODUmrjEwAX66J+elnNhhd19bPsjIq8tmw/Bu1jiXMD9QlMSo10lzo1yugO/TQijjnUNAahaeidCo70vX89Wq/AlRI/vaOcrGWzB9mFRuMJv4sbuWap5KK1V0FOo4upXHqJlE6DLkmnAuRNqe8fyfW14jovzsYaaOyy982yKHGmSP8tWTIelOz92YFTLpFp5BBDzIf2C6UrYhH8O+45RPzgb32pzRS0P6h+1HpJvFlrupNhp26w22wArGEAG5B/0RG1DiLJdlZV+HlT8iQdoF7yEWfAphTptXYDrQRRIo2GNlLddFhtIeiASD1ydNbzIX0cKOB3JZPF2rVlLVk4DbzceoXrg8XBp8y5FeLqQZQbYbzVuBmDyv74TgX7zKAvcuf4orj7y8xIxeS4YUV1qIz0TSU7MjZc+LaZ91u8KrcVPOBTJLeha5M3clhxTcBZrSVRPNTMknH2FUMVYYJazIMCWoxCx2+Zqff2T2I+kTvyYAS5OJ/UcXj8bXNQz8/+zmkmuMoC6mC+zMG8fH9m1fN0DoHr5vglviKdpSRdiJt qZ5I32DI tAFdZpRHPBzVkfNtZy9s10pHtzC4Us2ZvWttbu00fwYAwBIvR5RaNyuN/ciRdVtuMpA/GMT3gTW0Tm8iFglkWP30f1WDXr2JIdgB9mrbXhbalaZEt7uEv7hi0DGbhU6nZlgx4F7xWobqMOILhvqPOvEp8xwI8tlh3nzxRjz1hZ1m60g63OQSvtHdDPiIs5NTP0xZdt76hoDcHLqD3521ezDeRsVGw+0l2hSb6p3HtzfmDq4phEuP+iAx4U+3UX1dMHh9Y+RSISBk7OK3WGaccBTLDefxNPB3q2rW6xMDocb0klAKtHpJ5mTYPGW/x5flIkWLNGQhMDZLDeWAo1bB2XcZgA3OSi0epEWq8j85KoxIC+cJkJ6/TWysIWzsM32v32FFyXscOUedlueFH6Lhr2kKk8QRaVZQ2R+7TRD0SObmFDZiHcT9E6haIcV3bMPa/FDHVi1sceIeIAZoQKrK7iZiPZGQfR2Txrk3fclxPMpeJoz2X0PQhY3Ryv3F2Qy+fy9899GGHo43puhN28TyTzvIxG/IppgxS2eoZ0fuwmhfrzrCrv8sRXtT758BuRodeTpaI6zWyiK6mF48= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000025, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hey Jason, On 27.01.25 05:15, Jason Gunthorpe wrote: > On Sun, Jan 26, 2025 at 04:21:05PM -0800, Alexander Graf wrote: > >> Yes, this is easier said than done. In the user space driven kexec path, >> user space is in control of memory locations. At least after the first kexec >> iteration, these locations will overlap with the existing Linux runtime >> environment, because both lie in the scratch region. Only the purgatory >> moves everything to where it should be. > This just doesn't seem ideal to me.. It makes sense for old fashioned > kexec, but if you are committed to KHO start earlier. > > I would imagine a system that wants to do KHO to have A/B chunks of > memory that are used to boot up the kernel, and the running kernel > keeps the successor kernel's chunk entirely as ZONE_MOVABLE. > > When kexec time comes the running kernel evacuates the successor > chunk, and the new kernel gets one of two reliable linear mappings to > work with. No complex purgatory, no copying, its simple. > > The next kernel then makes the prior kernel's chunk ZONE_MOVABLE and > the cycle repeats. > > Why make it so complicated by using overlapping memory??? I agree with the simplifications you're proposing; not using the purgatory would be a great property to have. The reason why KHO doesn't do it yet is that I wanted to keep it simple from the other end. The big problem with going A/B is that if done the simple way, you only map B as MOVABLE while running in A. That means A could accidentally allocate persistent memory from A's memory region. When A then switches to B, B can no longer make all of A MOVABLE. So we need to ensure that *both* regions are MOVABLE, and the system is always fully aware of both. Alex