Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp5871176ioo; Wed, 1 Jun 2022 14:34:28 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzDS25YiD1Uxfj9zQVUoBiv04VXWD5urDFKpjqRDPPA21fay6hbqQmjIgATuxUEFpFlB4Qu X-Received: by 2002:a17:90b:1d08:b0:1e3:2a4f:6935 with SMTP id on8-20020a17090b1d0800b001e32a4f6935mr13944835pjb.174.1654119268447; Wed, 01 Jun 2022 14:34:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654119268; cv=none; d=google.com; s=arc-20160816; b=ZSAxmNYJSjWFoeFtmmGoWCTojTA8fO/VpHqTPQf+le4hTaq+rlDq77JwXzZbAv/wwN sOEL8UW5/TlAu7+Sl83TqVL5Ih6r7LpvFqDDQBB8V+eIVizQ2HxeijYV+6ZZNKlv23Vd STGmUH606h3z+skYzmTb0bXyxcTC05ihppfje03L2vTTKR7N4QUhmecjHVn2PrzrEO0C u2lI6wCVy4/X3MAdAkZyLX76jag52YGni9LjeNv3jA546Z8gWENjLFEqE31oio9jBiNW 8Zqf2BCx4B9sHDIwamp+A7Et7PK1klYZaj7A5Lrb6uidegiMVOC6Ac+mKLAKePuCj406 ylOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=Wkd+qK1A5XBz5WZBnQIdi6DW33K+oMosCMS+4sZy/cs=; b=M3Y5HwmMIHjC5T/WvcE9KL3G5POQLHmKKtEGIFovC/rWY9xDLVg948tSGnMb7K2JXr OjEtjawIeHe1iWlvNLsfd1w2+jEFCx+VRRxs82405y+c6dQtNgOadqHMHr5qXj2uPh9E l3xJiSXywvXg881vRZwK+StF1fhXqAKfByVxW+1OhdWgDs8XFgOFG1/Q/Js8ZtV9o3iX usD3NJZ1J0SsyZ2VQFNrzGfznlGewfKkzZUpXMXg3zEz9gvsRImddq43EHye3hhTCenb ZeEE/6Oeb0E83Za+rEeWBlcz0mi/dsD3yvt1ZbuCVE00uBYBYhl0/NtfzP4h3KCY2z59 WEzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="AGVDXW8/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id k185-20020a6384c2000000b003facc0b7a8dsi1899699pgd.710.2022.06.01.14.34.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jun 2022 14:34:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b="AGVDXW8/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4DC9232163A; Wed, 1 Jun 2022 13:22:28 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229833AbiFATsT (ORCPT + 99 others); Wed, 1 Jun 2022 15:48:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53514 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229454AbiFATsO (ORCPT ); Wed, 1 Jun 2022 15:48:14 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 703DE1CF14A; Wed, 1 Jun 2022 12:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description; bh=Wkd+qK1A5XBz5WZBnQIdi6DW33K+oMosCMS+4sZy/cs=; b=AGVDXW8/nu43WRDD1uEPuOrwI9 QhL8aaFxX8SyDpgfEbqrvquPDhrASGgMBINTb5sv+WrH7Xh1sDd+n5Agn78lUIaSslsWWcG+aDLRX 58d0g5oAaZy8W/AHowNwVTzGv9KWJrSjhiPqUKaiwj2IbyUal9XsN2TUZY0LiW9ZmMGJNHUdgT6CL SBccDuSyXo4Bk96TwW7Le6bBfgHn12WoBvV6qqqhr1tCnkFiJ927xRMQDxKQlDSjMjbksTP3TWZk/ rTsCrcf9n+FtYzXV3GDBCUG2yI+aicquUJWjcO5Ph84LXWBe+qfoMoObnSkPW0dybPx/KvY6mBwVF MfoIpimw==; Received: from [2601:1c0:6280:3f0::aa0b] by casper.infradead.org with esmtpsa (Exim 4.94.2 #2 (Red Hat Linux)) id 1nwU71-006YNd-JO; Wed, 01 Jun 2022 19:34:35 +0000 Message-ID: Date: Wed, 1 Jun 2022 12:34:24 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory Content-Language: en-US To: Dionna Amalie Glaze , "Gupta, Pankaj" Cc: "Xu, Min M" , "Kirill A. Shutemov" , Borislav Petkov , "Gao, Jiaqi" , Michael Roth , Borislav Petkov , "Kirill A. Shutemov" , "Lutomirski, Andy" , "Christopherson,, Sean" , Andrew Morton , "Rodel, Jorg" , Ard Biesheuvel , Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , "Hansen, Dave" , Mike Rapoport , David Hildenbrand , "x86@kernel.org" , "linux-mm@kvack.org" , "linux-coco@lists.linux.dev" , "linux-efi@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <20220425033934.68551-1-kirill.shutemov@linux.intel.com> <20220425033934.68551-7-kirill.shutemov@linux.intel.com> <20220506153013.e6v4q2qhuhqumfiu@box.shutemov.name> <20220513144515.fx2cvo3rjued3vy5@black.fi.intel.com> <0c545c5f-3540-1441-7a7d-359b6795f43a@amd.com> From: Randy Dunlap In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi-- On 6/1/22 09:20, Dionna Amalie Glaze wrote: > The memory accounting in Linux is probably the issue. Both times I ran > the test were from a freshly booted VM. The test parses the output of > $(free -k) to determine the amount of free memory it should allocate > and write/read from, with a given stride of pages to skip before > touching the next page. > > We grab the third column of numbers from the Mem output that looks like this > > total used free shared buff/cache available > Mem: 65856604 4128688 48558952 11208 13168964 60942928 > Swap: 1953788 118124 1835664 > > So my workstation has 48558952 free bytes. We take that, give it to > memtouch to allocate that much anonymous memory rounded down to the > nearest MB with mmap and randomly read/write the buffer. > > For an 8GB machine, the UEFI will have the initial 0-0xA000 memory and > 0x10_0000 to 0xC00_0000 (beginning of mmio hole) prevalidated. The > next 5GB is classified as the UEFI v2.9 memory type > EFI_RESOURCE_MEMORY_UNACCEPTED, 0x1_4000_000 to 0x2_0000_0000. > The Linux e820 map should see that range as unaccepted rather than > EFI_CONVENTIONAL_MEMORY (i.e., EDK2's EFI_RESOURCE_SYSTEM_MEMORY), but > I think it needs to be accounted as free conventional memory. > > So when I see 2044MB free vs 7089MB free in my VMs, the two are > roughly 5GB different. Please see/read/use https://people.kernel.org/tglx/notes-about-netiquette -- ~Randy