From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8465EA45 for ; Fri, 14 Apr 2023 10:19:09 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 829305C019C; Fri, 14 Apr 2023 06:19:08 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 14 Apr 2023 06:19:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov.name; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1681467548; x= 1681553948; bh=3WBXbUqLLLeQq1ZCi/ry0FRNyZxe7SfbSw3k4IDdgYw=; b=Z ClIRosJvFYimXH424uFn+IMWuq7wHzSt3CljrY6r3b2AWz20JTr3/voTEg5m5Jwj UJozpW/Eb7z4fS8NJLngrRWiQwe9+eoOVt7aOHAQU8KHYLFuHpcZJ9KLPu/jJtH2 9khb9X0dhloRjI8UKC8rzGLqd4glPe/VOA+1sw47v8Kz2xTKBqAmvuIHRr2Hk9cb qkCx1iB5t55scuSTy14A81GS7dz2XtgBVN4oPJ1F8+Jje3pSWcAngphiyuKemx3f 5gvG9A4VrQlZBSySiKi8BqvxPS1CgAlqqjhMEMgsJmNEdYd+KfOodnUs9Md3q4qX aKeFlK5chukPhVnOAF12Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1681467548; x=1681553948; bh=3WBXbUqLLLeQq 1ZCi/ry0FRNyZxe7SfbSw3k4IDdgYw=; b=Upd2y1I6y+9hRCGMAhkcN7OzmAdK+ ZYWyZauB6wWOXiH4DJdR7jvPQF4zF5KAFENPCLq+iUnbuIbPxWvaRixT0yBUZDWB sURE8/aBRxo4kDgGlXUphkxSqWCNFJLcBsoXhTKFDVSmNnp/D+3t493rFbUl2G5m 3z7OHA3oU3wt8CMch2Ipsx0uZsyKbSEL8xR3x6AsfXqGa2qwbvzTwOpnZ0h15QFu yOoVpNQ7SoueL2JYoTHKrbUTt6bnABkk3OshYd7lnz0sYNwOyzoAwrcPb/l2hTse V/H/Nb6xu7Mwzmd/y/uH1C6F2FvXMRV1h25KH7yXB1zx++Pm/aVEoJ/lw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeltddgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepfdfmihhr ihhllhcutedrucfuhhhuthgvmhhovhdfuceokhhirhhilhhlsehshhhuthgvmhhovhdrnh grmhgvqeenucggtffrrghtthgvrhhnpeekvddvjeffheetgedtvdfgieejiedvgeejieet jeehieehveffueekfeehffdvveenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehkihhrihhllhesshhhuhhtvghmohhvrdhnrghmvg X-ME-Proxy: Feedback-ID: ie3994620:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 14 Apr 2023 06:19:05 -0400 (EDT) Received: by box.shutemov.name (Postfix, from userid 1000) id EE51510D7B4; Fri, 14 Apr 2023 13:19:01 +0300 (+03) Date: Fri, 14 Apr 2023 13:19:01 +0300 From: "Kirill A. Shutemov" To: Vlastimil Babka Cc: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Dario Faggioli , Dave Hansen , Mike Rapoport , David Hildenbrand , Mel Gorman , marcelo.cerri@canonical.com, tim.gardner@canonical.com, khalid.elmously@canonical.com, philip.cox@canonical.com, aarcange@redhat.com, peterx@redhat.com, x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv9 03/14] mm/page_alloc: Fake unaccepted memory Message-ID: <20230414101901.j3zoji6vmjzpjiec@box> References: <20230330114956.20342-1-kirill.shutemov@linux.intel.com> <20230330114956.20342-4-kirill.shutemov@linux.intel.com> <835dfe65-d9dd-0b16-37d4-920e97f1bca0@suse.cz> <20230403143915.uc4tnpgmssvpdqxu@box.shutemov.name> <20230403155011.aodnd5ratcyeie52@box.shutemov.name> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230403155011.aodnd5ratcyeie52@box.shutemov.name> On Mon, Apr 03, 2023 at 06:50:11PM +0300, Kirill A. Shutemov wrote: > On Mon, Apr 03, 2023 at 05:39:15PM +0300, Kirill A. Shutemov wrote: > > On Mon, Apr 03, 2023 at 03:39:53PM +0200, Vlastimil Babka wrote: > > > On 3/30/23 13:49, Kirill A. Shutemov wrote: > > > > For testing purposes, it is useful to fake unaccepted memory in the > > > > system. It helps to understand unaccepted memory overhead to the page > > > > allocator. > > > > > > Ack on being useful for testing, but the question is if we want to also > > > merge this patch into mainline as it is? > > > > I don't insist on getting it upstream, but it can be handy to debug > > related bugs in the future. > > > > > > The patch allows to treat memory above the specified physical memory > > > > address as unaccepted. > > > > > > > > The change only fakes unaccepted memory for page allocator. Memblock is > > > > not affected. > > > > > > > > It also assumes that arch-provided accept_memory() on already accepted > > > > memory is a nop. > > > > > > I guess to be in mainline it would have to at least gracefully handle the > > > case of accept_memory actually not being a nop, and running on a system with > > > actual unaccepted memory (probably by ignoring the parameter in such case). > > > Then also the parameter would have to be documented. > > > > As it is written now, accept_memory() is nop on system with real > > unaccepted memory if the memory is already accepted. Arch-specific code > > will check against own records to see if the memory needs accepting. If > > not, just return. > > > > And the option will not interfere with unaccepted memory declared by EFI > > memmap. It can extend it, but that's it. > > > > Looks safe to me. > > > > > Speaking of documented parameters, I found at least two that seem a more > > > generic variant of this (but I didn't look closely if that makes sense): > > > > > > efi_fake_mem= nn[KMG]@ss[KMG]:aa[,nn[KMG]@ss[KMG]:aa,..] [EFI; X86] > > > Add arbitrary attribute to specific memory range by > > > updating original EFI memory map. > > As of now, efi_fake_mem= can adjust attributes of memory. Unaccepted is > type of memory, not an attribute. I guess we can allow it override type > too. But syntax is going to be fun. efi_fake_mem applied too late. Bitmap that represents unaccepted memory for kernel created at kernel decompression stage, but efi_fake_mem= handled in main kernel. I don't think pushing efi_fake_mem to decompressor makes sesne. I would rather drom the feature altogether. -- Kiryl Shutsemau / Kirill A. Shutemov