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 23C0FCE7B19 for ; Thu, 28 Sep 2023 10:25:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 907108D0072; Thu, 28 Sep 2023 06:25:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B79F8D0038; Thu, 28 Sep 2023 06:25:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A82D8D0072; Thu, 28 Sep 2023 06:25:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 679E18D0038 for ; Thu, 28 Sep 2023 06:25:58 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 34F53B42FB for ; Thu, 28 Sep 2023 10:25:58 +0000 (UTC) X-FDA: 81285625596.01.D7625F3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 63DDBA000E for ; Thu, 28 Sep 2023 10:25:56 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QPcysUQs; spf=pass (imf25.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1695896756; 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:in-reply-to:references:references:dkim-signature; bh=AJu1zUMjVZ+lx0EEl0IqbzumrKDe4gTjJqCGJOtK7tM=; b=0tYzXH5RVPDpW959u9HGJC+2n6V6E4d3/SVJt8pjmPDsgnUuD/6FfIMVcmBRFy5q35ozaQ 8p71e2MONkBv81p4tgi0LhXJKtHG3EmZWa9OW//1I91Hwk+1v6uCSPjWHJO3r5eLdwBSid tqiLSzYDf+XhTioQikZNsDAwWNYSOQU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1695896756; a=rsa-sha256; cv=none; b=xrZkCLno+vn6moyqHyQHrYe/tgAl52XNSfth50GK66imybY1QnhRfoeu4odEJjTejAA7as FhQKUQ3uEuHRimN6W2qmXEVsqgfKqkjRpE8Eo+U0Y3hwu7faURv7uoqzAHryxb0nZYN0vq 3/4Akrzdiz4Vw85pc9SpL8jWRYq9kpo= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=QPcysUQs; spf=pass (imf25.hostedemail.com: domain of bhe@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=bhe@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1695896755; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=AJu1zUMjVZ+lx0EEl0IqbzumrKDe4gTjJqCGJOtK7tM=; b=QPcysUQsogtxjESyfFJuAhMJrJFcm9NmKkiEzXdmTPN8gJjU6F6fzuL8QVeKYGSn0663W4 SSRKRUJzt29Bx3HvR6+P0Y0t7/wnGMleoriWAVKAJY4t5SC2hISE/isy2rOXbxVUo/iEvF E22mWABnUREP7TtPpcQMm/MD+A07+g8= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-224-NZW55hpLN0K6FJOvmhO7Rg-1; Thu, 28 Sep 2023 06:25:50 -0400 X-MC-Unique: NZW55hpLN0K6FJOvmhO7Rg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 600CB18811FB; Thu, 28 Sep 2023 10:25:49 +0000 (UTC) Received: from localhost (unknown [10.72.112.50]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C4770492B16; Thu, 28 Sep 2023 10:25:47 +0000 (UTC) Date: Thu, 28 Sep 2023 18:25:44 +0800 From: Baoquan He To: Stanislav Kinsburskii Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, ebiederm@xmission.com, akpm@linux-foundation.org, stanislav.kinsburskii@gmail.com, corbet@lwn.net, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org, kys@microsoft.com, jgowans@amazon.com, wei.liu@kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org, graf@amazon.de, pbonzini@redhat.com, david@redhat.com Subject: Re: [RFC PATCH v2 0/7] Introduce persistent memory pool Message-ID: References: <01828.123092517290700465@us-mta-156.us.mimecast.lan> <58146.123092712145601339@us-mta-73.us.mimecast.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58146.123092712145601339@us-mta-73.us.mimecast.lan> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Rspamd-Queue-Id: 63DDBA000E X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: rwotsnb3ojax6kefma36m1b3zgerztan X-HE-Tag: 1695896756-254632 X-HE-Meta: U2FsdGVkX18kxO87O3LL/1bAxrw1RwjIcOfIZez2b6lhLvjA4oERFvix5sCURErkF7BmrDRu9C7lUxOWtXenVpG0sV9+9c6u1X7A4rGl3SmMwls0SIICCSyQvZezLrTGH9IwWG1nFXY4IcfHDGY2wliJT5rIzVNJ10Xj/m+Digp+kD4uHRWeggLCxzrfSgN9FxWuYSus5JoQd/Na//Tf73/70syok3QvwcF+sj/PYqLY3ajjjhumHDTlbR7wlslG5jTfkHr8nl2ZdJD8vrCo4jjHNC/g+zSFainKcKeHSXIYATkHsirx9I/y4Td4W7MBWO3HEpBF7nUDFNdWRoBPkQAlN/TdRXzyVDGN2pIiuagnPBnA9i4CcMEFCOjNAc1uVTDU9XlTs5bjyZtHnJR+Mp+N2KZzZEAuHTS4uhjXzu5X/rslA/8ZnRzMh8SmSYHti7SIdJDIMmWvhr7fMe23EuiHJaR5Gvb96lAD8j9WrhsJCTeDAMXQnajq3mPC8bDuOUaQ4l23tStjapPR+l/dc/XznL8Yx9n55fVcO1F8rTbj+jGFHU44peP2YgzS7rlqFwXZedmSlDwT4NRmN9RDHAZUkxIdaB9Mh3bZ5kpvvyjTgfE17iBEe/7rZsXGFrtWGuj29jV6scpaMLGjEP77bArcDDFYAzsdTOTCEHP0D5hsFb6c7V7WMHSvFPxj6imyO/aMiCSRIRzyfjRQzlz6gDYtkPmc9rLmTL+wj8L8VlcASW2w1hwLbj4GCLv2rgLS29cw04Np682Uu2wBSoDsACaKpaYyaxYUuuiRtcolcMo73mZyJlXzb2XHKZpi0Ci9y0T9rcX0x66D8SpFtjQUiBZofxzxPlTV3JnRXievhYM1Z8dlUNfu23/+UGIpsZ/sy2Pfe98lBA1wkZrMLHihjAeuMAQji85UqKIMtYBuS1w/+LaQDn2VhFZgfUipF3iJZz5Tezl2b+kPYbILKvc lNbbRpH+ D7aarumQoDquu5rAL8JgLIODNJ+ut+ls2VrRfNQtnhbyyf9ZhbR1TzqsmBtpls3SYM8QEdYpH6LIEF8K/u4u/44a0+6v9bV7EFtbY6jtceYfZFWYbb8WrJkmLgMUA7yWOdZBSGK5XjD6GzbMvlktgIH/2pXcqVCyfZfUwFX1Z8fKm7GwXQhs2eczsEfszajk5NRDjXCEQPw9+NdOEnZpZ7run8i0kvqDLVdZGXV1cVBZR9FA6gLs6Vit28UxzQC/F+Skm3lJuHQFWDFKzZay/ZDMg/Q== 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: On 09/27/23 at 09:13am, Stanislav Kinsburskii wrote: > On Wed, Sep 27, 2023 at 01:44:38PM +0800, Baoquan He wrote: > > Hi Stanislav, > > > > On 09/25/23 at 02:27pm, Stanislav Kinsburskii wrote: > > > This patch introduces a memory allocator specifically tailored for > > > persistent memory within the kernel. The allocator maintains > > > kernel-specific states like DMA passthrough device states, IOMMU state, and > > > more across kexec. > > > > Can you give more details about how this persistent memory pool will be > > utilized in a actual scenario? I mean, what problem have you met so that > > you have to introduce persistent memory pool to solve it? > > > > The major reason we have at the moment, is that Linux root partition > running on top of the Microsoft hypervisor needs to deposit pages to > hypervisor in runtime, when hypervisor runs out of memory. > "Depositing" here means, that Linux passes a set of its PFNs to the > hypervisor via hypercall, and hypervisor then uses these pages for its > own needs. > > Once deposited, these pages can't be accessed by Linux anymore and thus > must be preserved in "used" state across kexec, as hypervisor state is > unware of kexec. In the same time, these pages can we withdrawn when > usused. Thus, an allocator persistent across kexec looks reasonable for > this particular matter. Thanks for these details. The deposit and withdraw remind me the Balloon driver, David's virtio-mem, DLPAR on ppc which can hot increasing or shrinking phisical memory on guest OS. Can't microsoft hypervisor do the similar thing to reclaim or give back the memory from or to the 'Linux root partition' running on top of the hypervisor? Thanks Baoquan