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 7E94CC433F5 for ; Wed, 13 Apr 2022 10:36:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 138176B0072; Wed, 13 Apr 2022 06:36:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E8656B0073; Wed, 13 Apr 2022 06:36:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF12A6B0074; Wed, 13 Apr 2022 06:36:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.25]) by kanga.kvack.org (Postfix) with ESMTP id DF7766B0072 for ; Wed, 13 Apr 2022 06:36:19 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id ADB31255F0 for ; Wed, 13 Apr 2022 10:36:19 +0000 (UTC) X-FDA: 79351501278.19.9FC0265 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 18679180002 for ; Wed, 13 Apr 2022 10:36:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649846178; h=from:from: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; bh=Gww3nqiIUaE/hiebhaeJWaOYoxyisvc31A4eZ4yYvpw=; b=Ngnow8eEQQ1yj6ouJiAgH4RM5BPXkvWwRFhtul9Mbzs1dHQi6XNNdS71rXJ/9i1JI406c2 y6Z3wK+2cMDMlWNcyPsEYjFyIjkhSdTzxkLLZwzHuARSk+mmVFfLnRvO+nzs5y1Yer3SFe c2U4UtuRTkS/thWgBO41wh0qG4vIjMM= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-395-o8IuyX2PPiWDbwBKQHWqSQ-1; Wed, 13 Apr 2022 06:36:15 -0400 X-MC-Unique: o8IuyX2PPiWDbwBKQHWqSQ-1 Received: by mail-wr1-f71.google.com with SMTP id g4-20020adfa484000000b002061151874eso246457wrb.21 for ; Wed, 13 Apr 2022 03:36:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=Gww3nqiIUaE/hiebhaeJWaOYoxyisvc31A4eZ4yYvpw=; b=r51rbT2FePEG6wcgjmb9A+EfSU0Vd8SOZSmBPHH5aR9G3SM37tAvpqnHLjLEsJ7I4v aBcWDD34tlHEuya94T5pa97pDeKAv8xDy68TRy2XKHLaekoJCH74EBqpGD9M/w7kM8hE rjp7jGuLrRmEslaYJrG23dV+yzvxKLTR3q1+LQU/0+4FRk/BAwFh5sPLpgOpadDfXbjc 7FxxRuTMJkBMZoquDIzGHFBjnO09QUe6eoPiA9Pkz5f5FgVdBTZwgcvK2HKgRClgigvp 06wLpcpdkLwZAktEEnRrZ/UnJFdkQ/0R+EKAQ+BEu2BfS4/XLjzRjQeoztxrsL4vulHU INDA== X-Gm-Message-State: AOAM533k48FOK+Z9fEzHmH+ez3EXrFwmf47wo0zCGJ/+oww8B4SOOb5i 0iTXsIGrPu5tmwxXZG5qqu/4fZJZZlntVslLmFSYd43G5dzjeD5oPupR+YIjZmWIQIp0zLmhFKz /HpdAZtuvrIY= X-Received: by 2002:a5d:47c3:0:b0:204:5b8:225c with SMTP id o3-20020a5d47c3000000b0020405b8225cmr31433816wrc.474.1649846174380; Wed, 13 Apr 2022 03:36:14 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwQSMzkkc8N52AEUPOHLS9vbDtk6f23iQd0OLo4NpbTx/HV7xfp7bReFl1jssMbbsElB6nYvQ== X-Received: by 2002:a5d:47c3:0:b0:204:5b8:225c with SMTP id o3-20020a5d47c3000000b0020405b8225cmr31433796wrc.474.1649846174092; Wed, 13 Apr 2022 03:36:14 -0700 (PDT) Received: from ?IPV6:2003:cb:c704:5800:1078:ebb9:e2c3:ea8c? (p200300cbc70458001078ebb9e2c3ea8c.dip0.t-ipconnect.de. [2003:cb:c704:5800:1078:ebb9:e2c3:ea8c]) by smtp.gmail.com with ESMTPSA id t6-20020a05600c198600b0038cafe3d47dsm2255442wmq.42.2022.04.13.03.36.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Apr 2022 03:36:13 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2022 12:36:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 To: Dave Hansen , "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel Cc: 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> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCHv4 1/8] mm: Add support for unaccepted memory In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 18679180002 X-Rspam-User: Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ngnow8eE; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf24.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com X-Stat-Signature: 5z8ymbh4nck83het5kc6xc9u9k3bzpr1 X-HE-Tag: 1649846178-734368 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 12.04.22 18:08, Dave Hansen wrote: > On 4/12/22 01:15, David Hildenbrand wrote: >> Can we simply automate this using a kthread or smth like that, which >> just traverses the free page lists and accepts pages (similar, but >> different to free page reporting)? > > That's definitely doable. > > The downside is that this will force premature consumption of physical > memory resources that the guest may never use. That's a particular > problem on TDX systems since there is no way for a VMM to reclaim guest > memory short of killing the guest. IIRC, the hypervisor will usually effectively populate all guest RAM either way right now. So yes, for hypervisors that might optimize for that, that statement would be true. But I lost track how helpful it would be in the near future e.g., with the fd-based private guest memory -- maybe they already optimize for delayed acceptance of memory, turning it into delayed population. > > In other words, I can see a good argument either way: > 1. The kernel should accept everything to avoid the perf nastiness > 2. The kernel should accept only what it needs in order to reduce memory > use > > I'm kinda partial to #1 though, if I had to pick only one. > > The other option might be to tie this all to DEFERRED_STRUCT_PAGE_INIT. > Have the rule that everything that gets a 'struct page' must be > accepted. If you want to do delayed acceptance, you do it via > DEFERRED_STRUCT_PAGE_INIT. That could also be an option, yes. At least being able to chose would be good. But IIRC, DEFERRED_STRUCT_PAGE_INIT will still make the system get stuck during boot and wait until everything was accepted. I see the following variants: 1) Slow boot; after boot, all memory is already accepted. 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. 3) Fast boot; after boot, memory gets accepted on demand. This is what we have in this series. I somehow don't quite like 3), but with deferred population in the hypervisor, it might just make sense. -- Thanks, David / dhildenb