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 DA8EDC4332F for ; Thu, 2 Nov 2023 18:34:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69503280004; Thu, 2 Nov 2023 14:34:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 645518D000F; Thu, 2 Nov 2023 14:34:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50D9A280004; Thu, 2 Nov 2023 14:34:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3D88D8D000F for ; Thu, 2 Nov 2023 14:34:25 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1247940173 for ; Thu, 2 Nov 2023 18:34:25 +0000 (UTC) X-FDA: 81413864490.03.C4845F5 Received: from mail-qt1-f180.google.com (mail-qt1-f180.google.com [209.85.160.180]) by imf06.hostedemail.com (Postfix) with ESMTP id 5092C18001D for ; Thu, 2 Nov 2023 18:34:23 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=HlvLHGuG; spf=pass (imf06.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698950063; a=rsa-sha256; cv=none; b=xijcVkgiqxC551jnX8ktZ8TY4JtANBtZc79ZyiM5LkXmrlFyzpKyd0KApW4+vKgnpSYmm6 3yl+k+G1dLMqRysIfriQvfIvte6ast2/1zyjPTKGpCtvWJbv87ZhsBH9/b/WHM12YF8OkZ 4dhLActHY7vCGe+EwC2oabDAvcPiCaY= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=HlvLHGuG; spf=pass (imf06.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.180 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698950063; 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=L0vqehv1Of/uKbf/NHzSex+avddGRsxzOfkGwHtKkyg=; b=BXYt6TpNakc689ozd4MDquTC+WtgeM60mrrdVeCfxRdY5Ygho99A1movPwLaqtYTN6MJwf jrZSDgRd2Mx86NhT3De6xs/KWlLPuIBDG/BQneaRoBE0js99nfVo7ZgWxxHm11tdrFtJg7 nJliIC9FsP8YMCTxkBMsEWeErWTEBgM= Received: by mail-qt1-f180.google.com with SMTP id d75a77b69052e-41cbd2cf3bbso19587361cf.0 for ; Thu, 02 Nov 2023 11:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1698950062; x=1699554862; 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=L0vqehv1Of/uKbf/NHzSex+avddGRsxzOfkGwHtKkyg=; b=HlvLHGuGx++wiNyRq1gKUMXSB4XOx0SB72oA3f8dRodrSnFacpBQih1kaXpctQ2fsF k66cp31qNBNKfRVzxVne+xdGyxZ8uwO8pmkeky28Dus4dSA6692GLUsCBX83opyDlgoa xcGU8301aTdH3hNbgeMMBvhWlgIgA9eAD+1uBtRg+ilxKBlcPtfjNa9Z19Y9kPviPhKD jwsUMU6oNI/KuCCAVGPFd/ECcI6ld9ctL1atfFlLDUy7wRG2g5myCKQ6lIwR39tY0LvM d6G3zo7FpvC7b0NDVQhtyr/t0M/O+jyAEVM7cBgYZm1qrEWbhGqt64+/86ab7mBKEdDk Pg+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698950062; x=1699554862; 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=L0vqehv1Of/uKbf/NHzSex+avddGRsxzOfkGwHtKkyg=; b=xQ2fDd3/0HV9DdKg6NLRpTf61+S/P49+jdE779AGJ2HVtZElnT2xo5pyEQmGEDyc9/ z63baENLmRuDO3VskHx2+u7smCZbB2NszmXHpQYV14sup+l2gUV/iHPOKUKmkBl6R0Qt QfC8OBCqiU1pLbsYFbe9SVo2wpe/g1+Zh37jw3wmIZJeuVBhECtn5ADoxFAr5gOGLFDm RRdSjVKJrnZIjwFWXr4If7HL01mQFWRVmRjU/IEcLUv9LZb4R8oneLORdn8Mm7YQNBQt TZ9zkOHssI0eLWDD7zKJccBcPRlD3A4Y1U2nq5aqaX/+mLiNxT90KAZXy7lSlNvzUr7+ QgdQ== X-Gm-Message-State: AOJu0YxFx2bngchX34nLYvyMHIHVaZ4RFDnveaJ2o4EniTZAKxvtD3XH ivaeSQdlPJ/KCViKQ6knGDI5v12qnE5yKmYQBCqGIA== X-Google-Smtp-Source: AGHT+IHli5W9pg027z3X7N5yytmKodloxVZvhxda6fBntxwV8IV1XJcayCtmXiUfhXeuIvSC8E1lkCREGDZtsGgqt0g= X-Received: by 2002:a05:622a:148c:b0:403:a662:a3c1 with SMTP id t12-20020a05622a148c00b00403a662a3c1mr489774qtx.29.1698950062459; Thu, 02 Nov 2023 11:34:22 -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 14:33:45 -0400 Message-ID: Subject: Re: [PATCH v5 1/1] mm: report per-page metadata information To: Wei Xu 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" X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5092C18001D X-Stat-Signature: ued751qwebftzwjefnga3pbue1s81ecf X-Rspam-User: X-HE-Tag: 1698950063-793854 X-HE-Meta: U2FsdGVkX18N6kGpoTbw/tChvRiwufGlSf5AuCzTFjpwoxldH7XHnEF0EaOxoWaovSzqLh23MqwN/HsgIp+RRTMdkaNGQDVkO/72SEvIsAPylPX/UOTj//Kw81JFW70/+Q7BJQP2h6XZvrtChFKEIM0ImVOpIXN1M1evOOoppxymjORlawQBSujvcwDqaoBbWMCglHbjksiwlMTcyVZOxh3xhcWGkDBMGKiKm9qBnued9fjrF7QWda/1xYhBFGE95xvG48AgUXoXqnpSP5eAxUUiLhgsFLXpvc98/jwNhwGHYs6wo6Hz48JobdjEds1klvJlriKXs9VY9k/Mdb774+PBVnFvRrdHU0i8F1HIgEeZkqBf6iPQ9ZVSH4gonejC6RFDbfmM8N6dLixyoR5b8lZX6IGAo8EL+mGFkCJ/ND5nXLWso81fkQy7A0+sRiPcqcCAV3Uh+5iu88ZDWoiXX4DQfHjHoHaxqP6HHkoUsCU+t33JYLwpZDkad5kQhx3a7wJDWAqDddFcs4op/AXlBJt9KuDwlfBSoXnibLeAs6F73jtavhzpHk3alZb3P0bNfSPcVZCE9eX/hX/RlHkELRKYGUpWg2xOLfK3OOSZLIPNDv8MtgtO5AmTVCS7FcxCduhjLeBoW2jpFnF7HfwhLLWfE0YwkeLymD1iEjEAmi5r1n1gDgXDH3qpx43WrWUoK+QCsbOKA1zWAxd0Yk474NJymcCjhH+RlhRGLCZ4UFRmIVZlUtMNwFGEvpIKPiVkDt7MxUjhd1cZRmyjUTfI6YQQDwBOHXhpIiuJtURMcd97ch7htn/efSBY7zuJ8AtWvs/l81LjMTZYjzhxBgQNN2611aVP5SJ2EjProxaXAbzv2vqKi0VOUpSUeQviFkLUL70JDgj8H2U8U1kpcDtuIzZiXU7BftkMPiYZKZ4Ur7CYlnAGVeSXDGL0bMVBSSdaF4w2rZUJUhj3js8FdcM QhVaufVN ea8HJbgdK0G7jPFBF2tGPd3GgeUmlyt0vgm8J3Tq3dCq5LFoZ8oaj1aiKTYs3FFzOCby5/1wKv56GecWC3fEdKq7A86dA0TWEIN4BhApuuYBmdyKGHZR10atbyfpCmVw9VPCXhhIw2zVeBZaFKSMt6DjSnlqLF6mQdz1/rS4XoQZHlvAyNnm2oOHpcvq5OSQof12QITH4SXNXL5hVwnh+xnJBYOkPxCjl/7RVr4+TR7K/0RV7lWL2vOSi8F3Mz+J7QiHCZY0qyMvLf7DuJJguhA9WJQ== 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: > > > 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. > > 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" 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. > > > > 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? > > > > > 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.