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 E4213C433FE for ; Wed, 13 Apr 2022 15:36:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4041D6B0072; Wed, 13 Apr 2022 11:36:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B3926B0073; Wed, 13 Apr 2022 11:36:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22EAE6B0074; Wed, 13 Apr 2022 11:36:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 0CE8E6B0072 for ; Wed, 13 Apr 2022 11:36:50 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id BBF5825795 for ; Wed, 13 Apr 2022 15:36:49 +0000 (UTC) X-FDA: 79352258538.05.4BD2902 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf02.hostedemail.com (Postfix) with ESMTP id 97C1680009 for ; Wed, 13 Apr 2022 15:36:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649864208; x=1681400208; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=oIiCjJKpo00HkSNcMJpuGaaA17RzsSWMzH4oj7iHyy8=; b=gozLYdAFJRKB0yVfXrLhkkLcGfXS9uih5ayqMAIGfih/djqi5HdTgEdm Q0YJrcj8OC+3m2HJvyvoAYN9aP4uc4+Ktwl92RG0D5W0z1GwPXtxGy9Hc sUZDpdwaVVqcGhqwun9k9vXJjxIvHjfBtZf7gQWKnf05SGtrxcUHNzmm6 P3aZvqvcMv9AF2EpHMrqknjfqVo8AWkYPdWi44L9dPB/Bm6O4lXG2/bWL /CFQBfyfHVrYVh9kFPTrk3aw+H30uwjOig/Y3f8Ki/xDg5QN66fjXkLfO J9uDQwx157EzlvmSj/CzvFeOLTxlcIgbJgfCVE8tSY1jw4jWkRQ+TlOxm w==; X-IronPort-AV: E=McAfee;i="6400,9594,10316"; a="244584862" X-IronPort-AV: E=Sophos;i="5.90,257,1643702400"; d="scan'208";a="244584862" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2022 08:36:46 -0700 X-IronPort-AV: E=Sophos;i="5.90,257,1643702400"; d="scan'208";a="559791794" Received: from jmsepko-mobl.amr.corp.intel.com (HELO [10.212.61.150]) ([10.212.61.150]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2022 08:36:45 -0700 Message-ID: Date: Wed, 13 Apr 2022 08:36:52 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: "Kirill A. Shutemov" , David Hildenbrand Cc: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , 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 , Varad Gautam , Dario Faggioli , Brijesh Singh , Mike Rapoport , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Mike Rapoport References: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> <20220405234343.74045-2-kirill.shutemov@linux.intel.com> <93a7cfdf-02e6-6880-c563-76b01c9f41f5@intel.com> <20220413113024.ycvocn6ynerl3b7m@box.shutemov.name> From: Dave Hansen Subject: Re: [PATCHv4 1/8] mm: Add support for unaccepted memory In-Reply-To: <20220413113024.ycvocn6ynerl3b7m@box.shutemov.name> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=gozLYdAF; spf=none (imf02.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 97C1680009 X-Stat-Signature: y6uogbicp86od9esjftitj9zwc7sjowp X-HE-Tag: 1649864208-846806 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 4/13/22 04:30, Kirill A. Shutemov wrote: >> 2) Fast boot; after boot, all memory will slowly but steadily get >> accepted in the background. After a while, all memory is accepted and >> can be signaled to user space. ... > Frankly, I think option 2 is the worst one. You still CPU cycles from the > workload after boot to do the job that may or may not be needed. It is an > half-measure that helps nobody. Let's not be too hyperbolic here. "Worst" is entirely subjective and it totally depends on your perspective and what you care about. There are basically four options: * Accept everything in early boot * Accept with deferred page free * Accept with kthread after boot * Accept on demand and four things that matter: * Code complexity * Time to a shell prompt * CPU/Memory waste * Deterministic overhead Did I miss any? News flash: none of the options wins on all the things that matter. We're going to have to pick one (or maybe two). I'm also not horribly convinced that there's a problem here worth solving, especially one that requires surgery in the core of the buddy allocator. This is essentially making a performance argument: it takes too long to boot if we go with a simpler solution. Yet, I haven't seen any data. I think we need to go with the simplest approach(es) until there's some actual data to guide us here. Here's another way to look at it: > https://docs.google.com/spreadsheets/d/1Fpv0Yp0CTF5_JXHR2pywvNtImTwUVGTxDMlJ5t8qiis/edit?usp=sharing