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 93A20EB64DD for ; Tue, 4 Jul 2023 14:37:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3212B280083; Tue, 4 Jul 2023 10:37:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AA44280076; Tue, 4 Jul 2023 10:37:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12462280083; Tue, 4 Jul 2023 10:37:56 -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 F1DB0280076 for ; Tue, 4 Jul 2023 10:37:55 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C30101C78EC for ; Tue, 4 Jul 2023 14:37:55 +0000 (UTC) X-FDA: 80974183710.18.01601B8 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf29.hostedemail.com (Postfix) with ESMTP id 814A7120029 for ; Tue, 4 Jul 2023 14:37:52 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=cHRac2VR; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf29.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688481473; 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=w3/eVaz1Sv3ukoIgcwC3gk343WJOF5YNTAEGH5+JlNE=; b=Fn9kG2YTBbmmIXTQ48FekmnWWJRjcHwdnqusi9LUQMnM39oLdqNWY63S5fHA7ijt7FlhOJ t7yi0GmnfSqLNFotSvtnXhohH8zPkIssdL50jgDjptUJMK3w/4GhXwDMr7gSyynCeL3E4I z+Fq2qPlHwpTk7ObPO6gXynxYoPzQNM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=cHRac2VR; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf29.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.151) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688481473; a=rsa-sha256; cv=none; b=zio/DJbHXlHgOo7BxD3b1o1fRZ/4RGqcns+wriEzgXkYmloeJ9AFVUMzuWlYlTL1s0iKUZ 1NPfM0fiMKYUE+lGI//RSCSoj6u4j2NIYkjaUgUclSW6TBMX+qEGXXr0XC7un9zzZjrk3O 78DF7P8bwym8ei7ppWH3HIlyOC+9cz0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688481472; x=1720017472; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=3uPK0lQLnODbW5urZpqsXqNoSRHmvwzicJIhGoLTkFM=; b=cHRac2VR5o82NaMCQMCS9Kg4qvxFRdWLKjJKWAA2OLk3tFwz+L14HD97 tAuj93eNizJv+2TdrwiPa4hNZ/Y8bVPYs/RCm842G9PHmaqPGX8DnxnIf Jj81Z18/oHkd2enBoqJzeyu1knmP4ZNyqLO16G7smLDcazivsEaGAd0vC QNXxsWrfRbSWVECv/YM5zHW9OtDDmKXL/paeaZxkeQ33p+WftKZThpZvF AklCU999yQf+VE8cOBGndWJ1pzgVObLRlZyMDa1fNScrykKbUGIGko/NY nDoxYiFH36Hbe+VhqCoE3YZRsfqlrBKh+qc9OiLwuczsd2y4nmRKnlJMv w==; X-IronPort-AV: E=McAfee;i="6600,9927,10760"; a="343469406" X-IronPort-AV: E=Sophos;i="6.01,180,1684825200"; d="scan'208";a="343469406" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jul 2023 07:37:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10760"; a="718940604" X-IronPort-AV: E=Sophos;i="6.01,180,1684825200"; d="scan'208";a="718940604" Received: from posikoya-mobl2.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.49.196]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jul 2023 07:37:41 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 27C2A10A08E; Tue, 4 Jul 2023 17:37:40 +0300 (+03) Date: Tue, 4 Jul 2023 17:37:40 +0300 From: "Kirill A. Shutemov" To: Mel Gorman Cc: Borislav Petkov , Andy Lutomirski , Dave Hansen , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Dario Faggioli , Mike Rapoport , David Hildenbrand , 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: [PATCHv14 5/9] efi: Add unaccepted memory support Message-ID: <20230704143740.bgimyg3bqsgxbm47@box.shutemov.name> References: <20230606142637.5171-1-kirill.shutemov@linux.intel.com> <20230606142637.5171-6-kirill.shutemov@linux.intel.com> <20230703132518.3ukqyolnes47i5r3@techsingularity.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230703132518.3ukqyolnes47i5r3@techsingularity.net> X-Rspam-User: X-Stat-Signature: gp4fo63p5nq7apdnaq6qahukmd35d6i9 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 814A7120029 X-HE-Tag: 1688481472-158705 X-HE-Meta: U2FsdGVkX189deifB1rYvWlFCZj3MP1UyR0YKIFd4WizXG10O6bG3BjKpyel5bWBwOAprzZcrR/XQjssQ5+0E3Fr7dx/MiG655hMR6bJR+t5EONrsQDeB0CWgCh8/QK6PX5LI2EZUjGSXwAA7AriyyL/apPnno4jtxMreKpKnE1/ip1igBxsQDs33odVeRqcunEZn/mkPrx7FyyAsbZbbSP6kEhc5y+Raal5VEn4t/Ham4qs+9usyFaxQNsfuVpnKESSjpdiH8hjZEKGAmqOapa2gANOmlsbcvkXng1GX4INLy+1nrTvRtJb9n0vG2YNGjGFi38IFldmqJLtUsYzkBcrQsVG+2myLhJrF7w8af7EpsnTpk8DPeKBUxLH1FnUUhJZc1Se2AisFm2BYJEK1AWJ+wRWR1R1l6l0T0JahVCBBzt4hF+xPHH8QGvxO/K5TSAqt1GtPAenTwHKyjCQ53CBgYZhdbl4rdzZ1yx91SHK4ftLR6AiwLFK8GrF+63z3vK9qLY2uGhRd9FoWqQVl/Kvn1Ai871YbVmeJA/8z/a2DAQ3Gy3UwevM0XuE6MJWYci1b4h0EVcNVJPznRcnd4Ua9swfmEz0wVI5gfXioRuUjYhiPVyEXAe+bL8LVxZd0tO0pNErb5mt6X4UU4g1xFAL+idyn6hhPhHX0gssk1aX8pv1g5J01Y+LRUKPNLjlQGSGqLoCezYFwLvaj5nCMpwTV2B1ECSeNi5q1d3YLiZqS7p/4wFmSr3Cg7hEEZqptsAlFPNuQlEXAvseT+NrVfKujOAVx0CYKLbLm6pb9PjHf86Vl7Hu76Jk+B4xT4iQizWWnDJ8Cv3MMYqV9ubZR9H4qDn17fGvCX7CH+o/4S76avLTRKIul7q3BBGTlFKDJ11waoidpX++R7BasFqsJThCIieZvRylwtAKcDs4WRZTdXKx+3ZNS0p6H0h/QJUr+j595ySdBIaaJW713Yl KU67mbHK Ya/rYIR25tC/APNU8XQBK6bLwl69WhMtCcQbxPTNcFr0+OPSpQutlDQkhpAtUvU2bDIdFjL9vrCuUtXO8i2TwVGuloe2mwcCHJIG28/IreZ1liwfqCRphF1g/1fxucTnztdpEKBa7S6eU6XnokOTPBzBlxQmYrp1NLCGEFGOycQv5iGJiUGTwxlyEEI0ddAQoy4J2NEvIMyTAxt4zsX30NoA3OQ== 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 Mon, Jul 03, 2023 at 02:25:18PM +0100, Mel Gorman wrote: > On Tue, Jun 06, 2023 at 05:26:33PM +0300, Kirill A. Shutemov wrote: > > efi_config_parse_tables() reserves memory that holds unaccepted memory > > configuration table so it won't be reused by page allocator. > > > > Core-mm requires few helpers to support unaccepted memory: > > > > - accept_memory() checks the range of addresses against the bitmap and > > accept memory if needed. > > > > - range_contains_unaccepted_memory() checks if anything within the > > range requires acceptance. > > > > Architectural code has to provide efi_get_unaccepted_table() that > > returns pointer to the unaccepted memory configuration table. > > > > arch_accept_memory() handles arch-specific part of memory acceptance. > > > > Signed-off-by: Kirill A. Shutemov > > Reviewed-by: Ard Biesheuvel > > Reviewed-by: Tom Lendacky > > By and large, this looks ok from the page allocator perspective as the > checks for unaccepted are mostly after watermark checks. However, if you > look in the initial fast path, you'll see this > > /* > * Forbid the first pass from falling back to types that fragment > * memory until all local zones are considered. > */ > alloc_flags |= alloc_flags_nofragment(ac.preferred_zoneref->zone, gfp); > > While checking watermarks should be fine from a functional perspective and > the fast paths are unaffected, there is a risk of premature fragmentation > until all memory has been accepted. Meeting watermarks does not necessarily > mean that fragmentation is avoided as pageblocks can get mixed while still > meeting watermarks. Could you elaborate on this scenario? Current code checks the watermark, if it is met, try rmqueue(). If rmqueue() fails anyway, try to accept more pages and retry the zone if it is successful. I'm not sure how we can get to the 'if (no_fallback) {' case with any unaccepted memory in the allowed zones. I see that there's preferred_zoneref and spread_dirty_pages cases, but unaccepted memory seems change nothing for them. Hm? -- Kiryl Shutsemau / Kirill A. Shutemov