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 C2CC0C4332F for ; Thu, 2 Nov 2023 20:22:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 314528D0056; Thu, 2 Nov 2023 16:22:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C4308D000F; Thu, 2 Nov 2023 16:22:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 165318D0056; Thu, 2 Nov 2023 16:22:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 058AF8D000F for ; Thu, 2 Nov 2023 16:22:33 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id CE3F440396 for ; Thu, 2 Nov 2023 20:22:32 +0000 (UTC) X-FDA: 81414136944.11.C1B6F21 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by imf18.hostedemail.com (Postfix) with ESMTP id E473A1C001C for ; Thu, 2 Nov 2023 20:22:30 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=HcYJ59bm; spf=pass (imf18.hostedemail.com: domain of weixugc@google.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=weixugc@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698956551; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=I2OmO/cSIWcHLs5m9Fp9R9ncrDst5FOA+aif1w7pvlY=; b=Z6zHFQBC82WSi5yZ+YB0h+SFwI1USmwRKDNBC9jej7YYsnloHdorU0wbf6pQffA4faYCaV H/XdotShX2XhloNWlgHG4Raa8apLBfMJSw5a6LXn5mMiwsSVmGckHExkYBGY9U+W9Z7J+E k6IWougC6wFs2t7CJfjt2vVT37mzzeA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698956551; a=rsa-sha256; cv=none; b=fSi50Yb6/MoMPbjznkVV8XoPjYQP2S5MzvUW5FLxqmRCzbwhAflOwwPW/b1hwTDtGcVlsV JxQwL3ExX+gf7uYMoRSenDEo8TqR+Ek0M2mRpNKyD4shKW5xAMDqzozMArEhWkFIciXbGd hJu/MtJzOhb2jHu5B3fOVhvJ7ZicvJE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=HcYJ59bm; spf=pass (imf18.hostedemail.com: domain of weixugc@google.com designates 209.85.221.50 as permitted sender) smtp.mailfrom=weixugc@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-32df66c691dso739277f8f.3 for ; Thu, 02 Nov 2023 13:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698956549; x=1699561349; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=I2OmO/cSIWcHLs5m9Fp9R9ncrDst5FOA+aif1w7pvlY=; b=HcYJ59bm+JJuqQCQBqRKq6vwp9zh/IT4pSpFVrX+hopVNLn0dIAgCVp0hPMTyX3Y3Y +10Dhf6f9oU+XpircpQm4ubE9QyNBUBEFO9eD8G33z1WpDkfG2zlikaJA8xi9YgYOzmJ x+TMvaKL7MQklRRpPSLaSL1N1Dc8KYwDtHBecGXzk/0/wdCIBSZ5CdY0YrBJhTQAKs3C 4HQujnKxkZcqz8IeOD2XhWkjQ1HnWBKWGipK3MM2+Ywan0miATJ4i7haIzzpejbRhzvr fcuzaP5bMCM7xUSZ2tQEr5biX3Usy8CBTePmTwte88L2Z3tyhTvTzrPVonTFPIZk+qlI 99EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698956549; x=1699561349; h=content-transfer-encoding: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=I2OmO/cSIWcHLs5m9Fp9R9ncrDst5FOA+aif1w7pvlY=; b=Ohzg81ya9O9qxJQLTwP8bUNfl9YKCAH8kvsxHy7wl3Rt8a9UrbDsdLur3q1BB1qPl6 ia3UJLoCcuEWZ26sVnLwLgpVYNUKciHoWd0OAhwwU9Td+XA4oUWJ1wb6r2jO9YIPLcNb Mkg4PWLEG0AtQ1wPrSvpAh/kkM+7uX7qaGhF5HochsamdpLSZEAvy2kdlm+4TAzB8bro PhJG8npMhZC4jAVB8sfTKWYV6n+e0yddSGS0TZ9BuMHSKl5ANlnqu5W8CqT0LS8TS7kd tPlwWtKWIgOmHd7m1ZYFsIrUZLgaOvT3/0E0/cv8XlWPQxaFr5OFegHF1E20RUEaCxZF YDBw== X-Gm-Message-State: AOJu0Yx+8ENfNyo0v/KyXe1M5OBcNaCNznWLuh9AQ8bt0uwJSpAvpkRI khDw+1xtoxsAgIV3SW1EAc2PKEZ5qwx50o2Bwoo3DA== X-Google-Smtp-Source: AGHT+IGWJTOQ+YhYnai3xZ5GlBXEVrHAqeGyrw5YY2JPOXTz5UPWJyE0CwKm1+LwoDz/xF/C9pX5+Zcy8M468XbZ27o= X-Received: by 2002:adf:f6c5:0:b0:323:36f1:c256 with SMTP id y5-20020adff6c5000000b0032336f1c256mr15140662wrp.11.1698956549087; Thu, 02 Nov 2023 13:22:29 -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: Wei Xu Date: Thu, 2 Nov 2023 13:22:17 -0700 Message-ID: Subject: Re: [PATCH v5 1/1] mm: report per-page metadata information To: Pasha Tatashin Cc: David Hildenbrand , 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" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E473A1C001C X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: o87usqzfycf5x4bxfeb1a1hd3rjz4fy3 X-HE-Tag: 1698956550-384700 X-HE-Meta: U2FsdGVkX19xN6MeB4V+zIB+Xaw0/ujTaTYhnR1gwiSqBDHPQHIKQIie0QeD/Z1try3vziCoY0/e1T0C0MMjBSrFeGnPl63GK2W5ZK+hrWnpX9fz/e3H8kWwp0AVfbOF3oijfOCtgOtvMrJ//lt1m9FkP7xeebo93ayR00SRTjhWEizlD7EWpuv1R/GfOnj9jDA3vS2OaFHlnPHb9q6ajjBvHDdvPu6XZmbj9YvEiQU9Ssp3w/Qbt9OAd64jl5wZ15xGSGWzwiFdIy280T5dS29JBnf1I3FQ5hkPnpy3LXoUCj/tHedLsXxIL++aCu7YzWwj+EewM17ji+wqGt9JRufpYMnWyVqbrgAmUK+IZIJidj+1sbW9SuLcgszuLVqrrQi27A1gKBVR+y6DZy/pVyZZOTyjkcoFyiiFINpmX3+MsDi706d3Hte96EId6GjBLfHKCjca6yHoqZO/Ss+Xv5sXJ7oQxEHnmcjV4tcBq/hp+krxS2A2Ob0Xqf2RZKprP80lfJP305/Bs9uDVIsL44/S3yhcQbDG+DRxbldbqCBxwAmIAOTZMUDEn8N6Q1keoYH+hwSt6jndfHWlY98H5PU0KM1KAxMJX0iqsdKAAwJRwqowSJ0ZaX8Vfau0anlYuu4GL4FBQvUlnt13AlVkW4y+vGE2tX8uRwWwudyzX38mZXo4xh4/DGLdnKPALWYa/G8+zvNCVrdxUmjScq7u4WOFJfKiaRpP46Z3AOpgJbUhJjSLcIMUOTZFUyKUn3n14j8jHfXmfH+aRTEwTTAfmyoutQtbSxSmnzy1flVHCh1r3gN6WKUAIgND2HWbQ7rHcjlSXDEczBugwDRgoqv57vLVZ822SPVOiRC1ckmAgdTuJTQsBK2VTorlFY5jaL2NH06RVAPy+tBXX8yne3YvT0SBsUvmwbVGg2FlShug9oMAjOF4xICmRasbs686Aong+7aAicSoUiq/MORUXW7 2nDVuJ4+ TU8nzDqvasfs8JXrYqVSMj9mjaxyQR2v7boFpVNYUn3GS+13RTUL9DIsqrQhGevXQlF3bFTah7hJ7KIBEYMJUE+Jss/bjRoLMD+Nf8kbiWoPFPKaaJ37KVatqg4jd/pg7EEXREPjzZUxjiOBwXQCVmlqYyINqjkbaK75N9FDdMZWclY8H9a8JFHT9FJjYxognxwEOzwW/GiS6cAOxW7ckt/hKaogP18E3/sPASggIEhokF0QdyVlD1enFFwaYf6qoTCvR9lsFfJSBfddlw908sqi4m3aMucbwQlmRcs1o7qZFXHvKJGg5YZ9PJfTEgMmINDR34l3GwWSFJIJJK4SRODxTMP5sxPeA79jfZkuV1ZO5c8w= 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: List-Subscribe: List-Unsubscribe: On Thu, Nov 2, 2023 at 11:34=E2=80=AFAM Pasha Tatashin wrote: > > > > > I could have sworn that I pointed that out in a previous version an= d > > > > 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. > > > > But this still doesn't answer how we can use the new PageMetadata > > field to help break down the runtime kernel overhead within MemUsed > > (MemTotal - MemFree). > > I am not sure it matters to the end users: they look at PageMetadata > with or without Page Owner, page_table_check, HugeTLB and it shows > exactly how much per-page overhead changed. Where the kernel allocated > that memory is not that important to the end user as long as that > memory became available to them. > > In addition, it is still possible to estimate the actual memblock part > of Per-page metadata by looking at /proc/zoneinfo: > > Memblock reserved per-page metadata: "present_pages - managed_pages" This assumes that all reserved memblocks are per-page metadata. As I mentioned earlier, it is not a robust approach. > If there is something big that we will allocate in that range, we > should probably also export it in some form. > > If this field does not fit in /proc/meminfo due to not fully being > part of MemTotal, we could just keep it under nodeN/, as a separate > file, as suggested by Greg. > > However, I think it is useful enough to have an easy system wide view > for Per-page metadata. It is fine to have this as a separate, informational sysfs file under nodeN/, outside of meminfo. I just don't think as in the current implementation (where PageMetadata is a mixture of buddy and memblock allocations), it can help with the use case that motivates this change, i.e. to improve the breakdown of the kernel overhead. > > > > > are allocated), so what would be the best way to export page meta= data > > > > > 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 d= o two > > > > > counters, we will still need to keep one that is a buddy allocato= r in > > > > > /proc/meminfo and the other one somewhere outside? > > > > > > > > I think the simplest thing to do now is to only report the buddy > > allocations of per-page metadata in meminfo. The meaning of the new > > This will cause PageMetadata to be 0 on 99% of the systems, and > essentially become useless to the vast majority of users. I don't think it is a major issue. There are other fields (e.g. Zswap) in meminfo that remain 0 when the feature is not used.