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 75BDAC4332F for ; Thu, 2 Nov 2023 17:12:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E8D448D009D; Thu, 2 Nov 2023 13:12:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E162A8D000F; Thu, 2 Nov 2023 13:12:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C95788D009D; Thu, 2 Nov 2023 13:12:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B3BE58D000F for ; Thu, 2 Nov 2023 13:12:14 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 80CEBB5C44 for ; Thu, 2 Nov 2023 17:12:14 +0000 (UTC) X-FDA: 81413657388.13.636961C Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf03.hostedemail.com (Postfix) with ESMTP id B11712001C for ; Thu, 2 Nov 2023 17:12:12 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=kRSUE9un; dmarc=none; spf=pass (imf03.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698945132; a=rsa-sha256; cv=none; b=wDdHEWqL1MKXBHpFrN3sA9mSk3u8NInSPOMHqSn7RASktqWdelIHfIbm+eEuG1qaXZBFV0 xPZTiMihIPu8MTRk5Q8UBVYvQfAOY4ZIMPo65g8xfh5ZadyoqYAVnaLP77YykJod1EAGcc YnSv/Zj7v+zRoKkX9g0Nv3N5LOlCtd0= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=kRSUE9un; dmarc=none; spf=pass (imf03.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698945132; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/hH8SjbUIXGq+UF4UxExRqQ+IVCN5t4ykfPIyUiPH38=; b=5LB3O/g/Kk/iKpulYZiDxlYaSTAaKACDB73MUfSFLhmWurLS+KCdierTSisU/ZTdCKJMuv 1Tax+ykPATDOqC/boUu9dvz7ax2gZwfH3OqLYxNUZ+xQ2rX17N+1eJHQIOptcNafaYO/Xh ll5fAmiht91G0YS+rT4TgS4FXt/vvkc= Received: by mail-qt1-f171.google.com with SMTP id d75a77b69052e-41cbf31da84so6368751cf.0 for ; Thu, 02 Nov 2023 10:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1698945132; x=1699549932; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/hH8SjbUIXGq+UF4UxExRqQ+IVCN5t4ykfPIyUiPH38=; b=kRSUE9unr+t8IDzdhtfvGRJqlZ3CAREpyH1FvpbcPwMy1EC1ISGi5ixHcRz5vtyFvP 4vOhwtzbY4C4c8oScGjQxf4C19Xf0sB4vTtbSbydMyfXoGTdsgU2+TSk1t5JDfgIuxko dQBrg7uZoelC8hbpdgERspeous+lG6sKKt+ic/BM1RqIgY19I9CT06C/ieJzhzpI8Ytb H5NzEmaW6SZwwiOS1aS86rD6X2w5nzRSTWP5jMnB/2NxxxIw2E1Q2NLY3RV7jTQEYmzM YTnRBgFukWCkE/fxM2PYLzdUXl38GQJvsGj4nC5frbt8KX8OQAiNtVuMrQh7/WHCZ+t7 6zOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698945132; x=1699549932; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/hH8SjbUIXGq+UF4UxExRqQ+IVCN5t4ykfPIyUiPH38=; b=JeO4PijETAoq/pWQYKoDA+Wpauk1elpexmCeTZMOrKYxP0vH5Rnt/727LU5FlZNELC UFD3cFcC0VfvKjGj3nj+VKWSgpSMXm10yAq/1At6TEgPtxTmlI9Gj5ceY1y+fc+ewW7k EwP3Q5YmuJeBZ/Wk1fh8pUny88g68jn3givqvXDYKgQu8Kk5ZE0Ue9AUWy1eN7V+tKiu EiNFO+uMNJ514Ew7MPxpH9+p4L5LbYEALUjZIBr3rniQEyA6PVJ/zq3tg3sHfuQbXH5G KYqCGi1LndVGZmHRZS1EvcWDdZ+npdyoEwrkUst2kzb2FBbrMwNz+LZNgY39FUwiTTXF i2ig== X-Gm-Message-State: AOJu0Yy5b4jCX29RATptkI/n/ziEneOvQbupLgRXr/t54PN7O63qiUVH 227zZjazq7QkIGqFcdlMAS17K4TIijrTVzNTq8UosQ== X-Google-Smtp-Source: AGHT+IHAJDw6t6f/1p5DCXhVNF5ZYBOAfpGF1Lzb87c+hYmXwYQhEflST5W0X8DLq3sBT2hMJLQQMPPBAaeVNc99U4k= X-Received: by 2002:ac8:5bc6:0:b0:41e:2db3:a066 with SMTP id b6-20020ac85bc6000000b0041e2db3a066mr23182516qtb.45.1698945131763; Thu, 02 Nov 2023 10:12:11 -0700 (PDT) MIME-Version: 1.0 References: <20231101230816.1459373-1-souravpanda@google.com> <20231101230816.1459373-2-souravpanda@google.com> <1e99ff39-b1cf-48b8-8b6d-ba5391e00db5@redhat.com> <025ef794-91a9-4f0c-9eb6-b0a4856fa10a@redhat.com> <99113dee-6d4d-4494-9eda-62b1faafdbae@redhat.com> In-Reply-To: From: Pasha Tatashin Date: Thu, 2 Nov 2023 13:11:34 -0400 Message-ID: Subject: Re: [PATCH v5 1/1] mm: report per-page metadata information To: David Hildenbrand Cc: Wei Xu , Sourav Panda , corbet@lwn.net, gregkh@linuxfoundation.org, rafael@kernel.org, akpm@linux-foundation.org, mike.kravetz@oracle.com, muchun.song@linux.dev, rppt@kernel.org, rdunlap@infradead.org, chenlinxuan@uniontech.com, yang.yang29@zte.com.cn, tomas.mudrunka@gmail.com, bhelgaas@google.com, ivan@cloudflare.com, yosryahmed@google.com, hannes@cmpxchg.org, shakeelb@google.com, kirill.shutemov@linux.intel.com, wangkefeng.wang@huawei.com, adobriyan@gmail.com, vbabka@suse.cz, Liam.Howlett@oracle.com, surenb@google.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, willy@infradead.org, Greg Thelen Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B11712001C X-Stat-Signature: 5zyrase4px9saww8hncsmqh7iwfypsf8 X-HE-Tag: 1698945132-901309 X-HE-Meta: U2FsdGVkX1++c5ivLxqRt9xDuw4ZeIIn1cVzyM67tE1ZiqjY+l0a+xW0Kz+x8DHXXtB4DgQAmfhS3NYF+SqtRouanvhx111mfjNqK3xBY+CKqkdVadWemTcaWnqjYYHchdUEkGkm3YfQCTONGrPU5zbTrpNA7O7RTOSg8dsl/qXuoE2ijMv00zRyd+GmGRXyWeEhbWWqc7EvZcleeLtSdgIhrxirjH+mDHWB6Z7BLl4zEtCm8j1AmehUhJ9jEVjaMbQ3hUSQ2COJfHtiVbBP38rF/xKyXKGgklJ2w63Waac9JHADej7wZvac8X1Hn+a2cL0IwVR1YAygxWeIbNN8Z1o0TQPzZvGt80QnCCOxEzqJrWGW+tiVOVIerVVzgvfZJPcAyP5IxcQv++5TftK0pScZ1N26HbYbizaNocuV1qqM089OqmYf2EWzJTFz/qkLjtpLNTSFchyU17Am2Rm/QogLXsekPwHE+A3wrdreXnQU0lLs0186b+/pOcYLM6UXz587FlLbWkdsgvl7TfOj3XfjubBOtPLGknPCojH4ZNZWULHiP1t4n5gE99NV5RmRfG2fxry8nTg5Me3/xNOK5LDxzGl4esLnbrtmpyJjf2UjgQePZZH9rxCB8LokhraUOL+/YtEl034IV2LJTLBW1rihjgWJhdMmkhkhleVFNMV3CEW8jt2cM9KSbET9IWGSDJCnDZ8Y/ANJdwodwxaoUGFFPKtyiUhuqOTyFiOz1NFOnhwQqB0ZUeVJevkef6NvD9qtQ4+WT/JdYv/6MUsizV7WNIWJ8qwAqfSjjT5RIAA1UvUzWYz6gOnZEH8kvIynOuQGDUuwqCRRA+NHQzx1pQ/wNZVHBsOjwBiq1xFHPGE2Kti5fWiugVmQlb6114jPGbRCZ4JEl7chE7F3XjM8qJItE9gQOR7Xug01NQ3XjXCwHVocNx7V0Mb8x5Z8p4i+lZ6DtFqolHz0hu5rSX4 i1fhEho3 bEWIPUoSUttLTA8iHaWeQB8YuedFFqDsiPAPfuu5alrngXUQFhv84Iu+9B3Zh+zb1d5h7+3Q9wl9oZ6Lu7Q5MOH4N3iYA2gHRGzj4LP87TXJ8D1mob00O1bKVZyxyDe3X73elglnu1l5vwBU5E1vwIBu4jBeoSfDYiIi3dduY7agu2epRvAZu7399mcmmFGzCN0kisN9UPVyzoj/LQlbNlyPG1Dq7hCi1KOp4OOX6VLn7TvPGyjAnsvIvjjy9TgQdw/81dIYVjYV48LbFzpQ97jtjvA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000008, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > Wei, noticed that all other fields in /proc/meminfo are part of > > MemTotal, but this new field may be not (depending where struct pages > > I could have sworn that I pointed that out in a previous version and > requested to document that special case in the patch description. :) Sounds, good we will document that parts of per-page may not be part of MemTotal. > > are allocated), so what would be the best way to export page metadata > > without redefining MemTotal? Keep the new field in /proc/meminfo but > > be ok that it is not part of MemTotal or do two counters? If we do two > > counters, we will still need to keep one that is a buddy allocator in > > /proc/meminfo and the other one somewhere outside? > > IMHO, we should just leave MemTotal alone ("memory managed by the buddy > that could actually mostly get freed up and reused -- although that's > not completely true") and have a new counter that includes any system > memory (MemSystem? but as we learned, as separate files), including most > memblock allocations/reservations as well (metadata, early pagetables, > initrd, kernel, ...). > > The you would actually know how much memory the system is using > (exclusing things like crashmem, mem=, ...). > > That part is tricky, though -- I recall there are memblock reservations > that are similar to the crashkernel -- which is why the current state is > to account memory when it's handed to the buddy under MemTotal -- which > is straight forward and simply. It may be simplified if we define MemSystem as all the usable memory provided by firmware to Linux kernel. For BIOS it would be the "usable" ranges in the original e820 memory list before it's been modified by the kernel based on the parameters. For device-tree architectures, it would be the memory binding provided by the original device tree from the firmware. Pasha