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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0CD0C4320A for ; Tue, 10 Aug 2021 19:23:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4ECBF60F41 for ; Tue, 10 Aug 2021 19:23:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4ECBF60F41 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 94A076B0071; Tue, 10 Aug 2021 15:23:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8FA6B8D0001; Tue, 10 Aug 2021 15:23:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E9616B0073; Tue, 10 Aug 2021 15:23:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0057.hostedemail.com [216.40.44.57]) by kanga.kvack.org (Postfix) with ESMTP id 615CE6B0071 for ; Tue, 10 Aug 2021 15:23:53 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0DA89231CF for ; Tue, 10 Aug 2021 19:23:53 +0000 (UTC) X-FDA: 78460145946.21.3071ACC Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by imf14.hostedemail.com (Postfix) with ESMTP id 1E6F5600B657 for ; Tue, 10 Aug 2021 19:23:51 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10072"; a="278723846" X-IronPort-AV: E=Sophos;i="5.84,310,1620716400"; d="scan'208";a="278723846" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2021 12:23:50 -0700 X-IronPort-AV: E=Sophos;i="5.84,310,1620716400"; d="scan'208";a="515958752" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.209.69.62]) ([10.209.69.62]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Aug 2021 12:23:49 -0700 Subject: Re: [PATCH 1/5] mm: Add support for unaccepted memory To: Dave Hansen , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel Cc: Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" References: <20210810062626.1012-1-kirill.shutemov@linux.intel.com> <20210810062626.1012-2-kirill.shutemov@linux.intel.com> <9748c07c-4e59-89d0-f425-c57f778d1b42@linux.intel.com> <17b6a3a3-bd7d-f57e-8762-96258b16247a@intel.com> From: Andi Kleen Message-ID: <796a4b20-7fa3-3086-efa0-2f728f35ae06@linux.intel.com> Date: Tue, 10 Aug 2021 12:23:48 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <17b6a3a3-bd7d-f57e-8762-96258b16247a@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none); spf=none (imf14.hostedemail.com: domain of ak@linux.intel.com has no SPF policy when checking 134.134.136.100) smtp.mailfrom=ak@linux.intel.com X-Stat-Signature: 9tjahi1bfop8a5cnqadd8gn5i6o7qior X-Rspamd-Queue-Id: 1E6F5600B657 X-Rspamd-Server: rspam01 X-HE-Tag: 1628623431-589905 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: > But, not everyone is going to agree with me. Both the Intel TDX and the AMD SEV side independently came to opposite conclusions. In general people care a lot about boot time of VM guests. > > This also begs the question of how folks know when this "blip" is over. > Do we have a counter for offline pages? Is there any way to force page > acceptance? Or, are we just stuck allocating a bunch of memory to warm > up the system? > > How do folks who care about these new blips avoid them? It's not different than any other warmup. At warmup time you always have lots of blips until the working set stabilizes. For example in virtualization first touch of a new page is usually an EPT violation handled to the host. Or in the native case you may need to do IO or free memory. Everybody who based their critical latency percentiles around a warming up process would be foolish, the picture would be completely distorted. So the basic operation is adding some overhead, but I don't think anything is that unusual compared to the state of the art. Now perhaps the locking might be a problem if the other operations all run in parallel, causing unnecessary serialization If that's really a problem I guess we can optimize later. I don't think there's anything fundamental about the current locking. -Andi