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 A1926C433EF for ; Wed, 13 Apr 2022 16:07:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25A5B6B0073; Wed, 13 Apr 2022 12:07:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 209F16B0074; Wed, 13 Apr 2022 12:07:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 091356B0075; Wed, 13 Apr 2022 12:07:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) by kanga.kvack.org (Postfix) with ESMTP id EB81B6B0073 for ; Wed, 13 Apr 2022 12:07:51 -0400 (EDT) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A35C88249980 for ; Wed, 13 Apr 2022 16:07:51 +0000 (UTC) X-FDA: 79352336742.25.5D002D9 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf07.hostedemail.com (Postfix) with ESMTP id 0D09840012 for ; Wed, 13 Apr 2022 16:07:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649866070; 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=QOkajocQ8odh3i+hVeTJ63TIENzeAVOjDB6rWovHQzA=; b=UHIRHKdaNGk4SBrBx7HwHJXCuwjgGgSa/Vw0YYtzSnCRFsNgcqSfOw2rYwtmfv/COUkxKr d+eBqd23BIB+AcbGQwIHN7FwHpXQcDDYiBRKYhCIi66AvbmgYXebfIZ03gMI5BegmHRUpG OnY+xppIf9JF5ZUlBtbSwDOGZwXfKXI= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-344-0l5m30wWPdOC8yhIBaGv0w-1; Wed, 13 Apr 2022 12:07:49 -0400 X-MC-Unique: 0l5m30wWPdOC8yhIBaGv0w-1 Received: by mail-wr1-f69.google.com with SMTP id s13-20020adfa28d000000b00205e049cff2so503319wra.17 for ; Wed, 13 Apr 2022 09:07:49 -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:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=QOkajocQ8odh3i+hVeTJ63TIENzeAVOjDB6rWovHQzA=; b=p//hBpcF3V1dzwCSHsIY949SHdFYGsfRinXGplbdZSnQVoyPk2GHasRWLm2vHcjaoJ +cDqaUjRfOkM0WRDRf9xoN0fgsCPPlgOkoVxOBPw6tIBsdp9pUxgCGdXkBYbVtmJEFOq 6wIwLDnVyqm+UbZGqLNmLWU72ZnUUzu9u1XHNtfHT+a2oPAxLg1gMY9OcdcyfbDNKAjj QBIR/P6PRz8AOphVYmtoVHKlBMlVsfFeSf0Pt8b6x5QXbqaQMqL0qGIYfbdne2bp5z9N zDzZlzBdUjuKjuNnKJ0B+/MH37iQ12aWKXEU+qwPrwitIlCaq8flrjtjDE8yFORWhjll ZVtA== X-Gm-Message-State: AOAM532UORRrDICoC/iNxVuUCbq4B05DFM1QDggwhJsGX0Th7sxqFz9R FoGWQVylCdK0qaP33sp6NJLrE89QRwc3q+4Qpdz1BKAza70etiC9trPoJ+S1jZA2/joQkxIwVK/ /+sJQ3Q9wMck= X-Received: by 2002:adf:eb86:0:b0:1e6:8c92:af6b with SMTP id t6-20020adfeb86000000b001e68c92af6bmr33002763wrn.116.1649866068379; Wed, 13 Apr 2022 09:07:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJymHGhx5mZYHX4qc0LA34JUWjZS8Rn5QEmfvMvUVt0DpiviRON0T5cX/n3xjfGY/yDNO9s2GQ== X-Received: by 2002:adf:eb86:0:b0:1e6:8c92:af6b with SMTP id t6-20020adfeb86000000b001e68c92af6bmr33002738wrn.116.1649866068071; Wed, 13 Apr 2022 09:07:48 -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 l126-20020a1c2584000000b00387d4f35651sm2895911wml.10.2022.04.13.09.07.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Apr 2022 09:07:47 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2022 18:07:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCHv4 1/8] mm: Add support for unaccepted memory To: Dave Hansen , "Kirill A. Shutemov" 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: David Hildenbrand Organization: Red Hat 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-Stat-Signature: 6bbsppt7a7y887mmwdm9z93gc3ja58t5 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UHIRHKda; spf=none (imf07.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 0D09840012 X-HE-Tag: 1649866070-745678 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 13.04.22 17:36, Dave Hansen wrote: > 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. Right. Some people might want to start their workload as soon as the pain is really over. Some might want to have a functional system before that, others might not care. > > 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? Nothing that comes to mind. > > 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. Simplest meaning: accept everything during early boot and don't touch core-mm/buddy code, correct? > > Here's another way to look at it: > >> https://docs.google.com/spreadsheets/d/1Fpv0Yp0CTF5_JXHR2pywvNtImTwUVGTxDMlJ5t8qiis/edit?usp=sharing > -- Thanks, David / dhildenb