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 7A9DDC761A6 for ; Mon, 3 Apr 2023 13:39:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D95646B0071; Mon, 3 Apr 2023 09:39:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D46166B0072; Mon, 3 Apr 2023 09:39:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0D7C6B0074; Mon, 3 Apr 2023 09:39:58 -0400 (EDT) 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 B1B466B0071 for ; Mon, 3 Apr 2023 09:39:58 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 631DB160B8F for ; Mon, 3 Apr 2023 13:39:58 +0000 (UTC) X-FDA: 80640188076.21.BFF4E88 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf26.hostedemail.com (Postfix) with ESMTP id 1844814000C for ; Mon, 3 Apr 2023 13:39:55 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=dEh5UzE1; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=WbJPtdz1; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680529196; 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=CBPTbLZUOtliF78vhoUgkDjz9De2UOd6RXubIlxxUKQ=; b=lh+h0T1ESTmLyIjtSncNRI5PMQeh5fI1QULJDZ4yFZ//yDdD9deMhD7IKIHfxK8iO6jbu8 MYzKvEIeHn5J55U7f0QMesGJ/WlJU2am0aqaYi2mvf9rHBcb/N0iSKrePJbxYkhoMEmONF 1Vpfh5dOUSXtDuAAYE4Q3t9hjB/h2sU= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=dEh5UzE1; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=WbJPtdz1; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.29 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680529196; a=rsa-sha256; cv=none; b=tmkaPjbgZU3VDCavWmxm+YNY0/TaERF9rMISgu4DjRs+TZYfIcyDnq31XvsuYy5lNVL8xJ 40tfSgArp7+BbS51AMNyN7kZNrDkouXloPDpyDXRZMWLMOfEAhBNKpTbmIQWnpaEabKSQa uOlQJWCvQGXbQzkSEjT2wZjZI0EWI+c= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 59B801FF74; Mon, 3 Apr 2023 13:39:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1680529194; h=from:from:reply-to: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; bh=CBPTbLZUOtliF78vhoUgkDjz9De2UOd6RXubIlxxUKQ=; b=dEh5UzE1UMQXLCM7as0vLJd3lLaAkNuz5oZm7EVWGb0tjn9HYVXCIAvDAUoukhgA70kPZB OtYnXIKmaVriUCxbdHKMQUsD9UIvzi3WA4Eijj1LeIMqYbgSXvSQJGY8bhxy+qCQT+CQWU Pm4kuCMToUXj8Y7O0X9pdm0g1sEUR78= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1680529194; h=from:from:reply-to: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; bh=CBPTbLZUOtliF78vhoUgkDjz9De2UOd6RXubIlxxUKQ=; b=WbJPtdz1aelIPmv4RiiH9qqqXo9se976+n4KO/1kCFFo7ccoNETeWtvQIc9EwVWEgmI0sl BQ95eQ4jYpieDNDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id CC90C13416; Mon, 3 Apr 2023 13:39:53 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id s08tMSnXKmQ4eAAAMHmgww (envelope-from ); Mon, 03 Apr 2023 13:39:53 +0000 Message-ID: <835dfe65-d9dd-0b16-37d4-920e97f1bca0@suse.cz> Date: Mon, 3 Apr 2023 15:39:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCHv9 03/14] mm/page_alloc: Fake unaccepted memory Content-Language: en-US To: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel Cc: 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 References: <20230330114956.20342-1-kirill.shutemov@linux.intel.com> <20230330114956.20342-4-kirill.shutemov@linux.intel.com> From: Vlastimil Babka In-Reply-To: <20230330114956.20342-4-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1844814000C X-Stat-Signature: t5ai9f443qefqo9ifa6tofzamrj4nsuf X-HE-Tag: 1680529195-597132 X-HE-Meta: U2FsdGVkX1+6xH8vnxahZF8tDDoEGwWwAPJXW0PcU4VDqhm5xT6tIkn3RSvRAZjCD7fcQXyi059c5aUcAYZ6QPiR+xGo9yAbfKCAAmjFGCC2IynMB8oVwvVCKwW+noKqRro5Gj/u1enATUvwvtiqXVZSF4s4wKNT2oCq7noaDhPSxolU+CQJAUu0raJPxo2uFvcAi/X7XpO3oIwnM5uvZRMHctl5gUPGWA52nvry0CtB/gqjXmd57KbJZoksV3LTslgOeJpqdk+uU+3yECu4SWKKu/NJIqS8zjTZYt7Q3SAQz/wqTRkRNaz4BG5rBFN7Uh6/e2XbpkwIuc4maeDXi9o4nPfqS0rr4lQJ34mkilNy+vM30czoEySE4/x+qhI2zGmv4oO4LpMo88cWeMzs8+ugnbcuRgz3HgGIlF76bVs/G/2Kj213lcy58COmm5ya0dl2QmaQrRjKJxYafSphtCS8ygyqgMEa/jYsYnntFbQbgrbSQoKTB4XKPrG5VExyK0DOLZXyfiHnoaYXcSsosOgeadrubsst/yBJGqqVNy9RncuySNguQaB3xwTe/uAydHstAEJzL6wo15YxSwO4R63w7JdWqUMXlCB+MxLp69DfW8ALB4PEng18VhdWtn9GS0HB9ADRRpOPGUvZ+GhgD9g1AGqkyI44x+Zr8qxP77IUj9AdN12R/OdJDN56ACMdunyWt5Lo6K9CCRwQmxH47i75pTEx63YrcL6E+ocjk1qyhm25j/Y8GMD/dfLrziQO/ntTrBqfTmqOtlrgJZuUIS2+koXurojSk+oV8hkCbjffHgZT+lmgf7uEtEkTAdYxLl+xc81ecWuFivdf76/mkrbXislTlNIYxcj3CyPoCYSURy10uLJvEXe7XZ9ce8/Uc8fQN5x8zs0DOVCrzU7YCQMjoARJ+y4bnCcCIkwyPSTzCDwmNscgu8DF0u/FIKVYGNfD94ALtuas64cCMZn Z6gzZtLw Ofo7Ct3Anf3Oe3XWlLf2NKs1hh2Xz+0YlJR9ovfeNRtEniz2h9wmrG386al34Wbvyhpe4QMl7SfzWfITklyu5OOd7XCWDRemVj4VNa0r0kVuYzjcIpJHTP3iAHKX+xrKEwir4vkiNNrmp1NJNI98Clp2gBJFSE6EO/zOwSRi1bSakHayti7u+MUvtgC1HhLxUvO+yzNQ0Aq79J8gCn6yMd48KbrHt9xSqT6ebRJ/e+12SOZ7bUcHvydcQWxZNe/iI/Z5qReb5hCnCWyP3PxhAsEsfCUhXw0+V8EZp 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 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? > 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. 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. memmap=%-+ [KNL,ACPI] Convert memory within the specified region from to . If "-" is left Would any of those be usable for this usecase? > Signed-off-by: Kirill A. Shutemov > --- > mm/page_alloc.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index d62fcb2f28bd..509a93b7e5af 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -7213,6 +7213,8 @@ static DEFINE_STATIC_KEY_FALSE(zones_with_unaccepted_pages); > > static bool lazy_accept = true; > > +static unsigned long fake_unaccepted_start = -1UL; > + > static int __init accept_memory_parse(char *p) > { > if (!strcmp(p, "lazy")) { > @@ -7227,11 +7229,30 @@ static int __init accept_memory_parse(char *p) > } > early_param("accept_memory", accept_memory_parse); > > +static int __init fake_unaccepted_start_parse(char *p) > +{ > + if (!p) > + return -EINVAL; > + > + fake_unaccepted_start = memparse(p, &p); > + > + if (*p != '\0') { > + fake_unaccepted_start = -1UL; > + return -EINVAL; > + } > + > + return 0; > +} > +early_param("fake_unaccepted_start", fake_unaccepted_start_parse); > + > static bool page_contains_unaccepted(struct page *page, unsigned int order) > { > phys_addr_t start = page_to_phys(page); > phys_addr_t end = start + (PAGE_SIZE << order); > > + if (start >= fake_unaccepted_start) > + return true; > + > return range_contains_unaccepted_memory(start, end); > } >