Received: by 2002:a05:7412:b795:b0:e2:908c:2ebd with SMTP id iv21csp576077rdb; Thu, 2 Nov 2023 11:34:59 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEbM5v/liZtg50HPzcuVo7R/4AhlDimGCXAwnCopcAPIrdlVdVGZL/uLT8Qot7qGbEAVXxh X-Received: by 2002:a17:902:dac1:b0:1cc:4b3d:1a8d with SMTP id q1-20020a170902dac100b001cc4b3d1a8dmr410958plx.17.1698950099276; Thu, 02 Nov 2023 11:34:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698950099; cv=none; d=google.com; s=arc-20160816; b=eT+kodbCahaLIzBfOVTfreFpkz74nM0kfKrLxbOm3XvakPqza7fNy6FIS3NsLQul1X O6jAeYAsjH/sCl+7DxLfxvW32icYeyXcU9hJ+ncaWDLBdW4fPqE3XxD9vibyRtIrFxvr sArwWJuEmgr+VICvXoUsdhq4YciIHYCXdmLdL1xpPVyzvqrVyjrgV+KdOZO9f20g434L X6t8hBxkV5GPNcdvD3ItpFDeBVNhL3f3ATxd79roZKEf5NZPq6YjhHAQH13K9j7kTT9x rdvEJQ3/nAYbsGvZWrKyklwBkytkUHvupwD6eLHmIJ95OpxWqOJ3ERJtuZK4wMyr3gcx X8dA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=L0vqehv1Of/uKbf/NHzSex+avddGRsxzOfkGwHtKkyg=; fh=LG/qRHl6NvcbOJIwP5ehkbx+ZMq6qm2lEK82MtINYRQ=; b=WcVWGJSzYBnHPRRMlF9WvWa8EiN21VWeef8FtExCysDGYL1Hypc6fjwGGCGyf5DY9i klLlRlqc+2PvM7Du8xyzGlFFMsmtzqSl4/r4OsQToCGsTDlFL78s02fLXUdxPqy35h89 76vkzBH/JFUiPJVyIvLq/LJ8gSDF71D2U/y3MG05L+ecoNzABiXV9K0Ipkxzp+lHgzzB 0QKS6COU62H97KxmbQmccj7H6ACOZkQtDND9SPBeCBMd6o8WvZ47BuqJ2S70Gb2WP+J6 RK18B/6fr+7dZJ9Rd06BCFNc/KnOHXb7WUM+aMynloXJqOk/dzNQ13Z5563kVyT1d7pp B2XQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@soleen.com header.s=google header.b=keEIs5at; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id ik2-20020a170902ab0200b001c9b15bf936si86196plb.220.2023.11.02.11.34.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Nov 2023 11:34:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@soleen.com header.s=google header.b=keEIs5at; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 99CD68381EF2; Thu, 2 Nov 2023 11:34:56 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234266AbjKBSee (ORCPT + 99 others); Thu, 2 Nov 2023 14:34:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234295AbjKBSec (ORCPT ); Thu, 2 Nov 2023 14:34:32 -0400 Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52AD312D for ; Thu, 2 Nov 2023 11:34:23 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id d75a77b69052e-41ccd38eaa5so10768261cf.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=vger.kernel.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=keEIs5atyxpQtTi3W81MbqQkrNpfNLwBg0KGH2gI44fi3hXGXBGDegv5+XmEZImGJu r1NDUTT8iwz+JGaQLXqmlu1cLBmxv5Rq0zViAp+j/rYeMvTou7vhUCHPK0UTLqmJQo2M nwN52bda7Fx2iQZBqR9SSXZHx0/egPzlBqgiRnWJlrnjpXYE7AznFqeEA1GlvIktrDAY 4TnUfXMMfsX3vEMyerE3EltJYDrrzgOkVcJRw+UQQYSgWTkm03E/1/9cgpRcbka5x7/4 utQVaGWax8FZUUP/C1fz5jGJl7q55zzLcMowZX4KwXGrPTclfIo4rBsthtVthcMpuF0t RriA== 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=SdgJZ5T8hOX1tKJapUZ7xITH7l1FK/AhSeiviEkLoCSNAXQPJUFIK9ejH9cSboDwhh 9X/tCJz8f5j3233TB4kmAGhAL+YmFKW3Oxc9xu/2OspRP2Z1v6aVU6pcH2kbyj7Xz1rK 0GBqCECoPL/UTG3UlJzVl8dD3CjspvEaboSN8ne4KrBAb3mJ0iXB6BpPYCgeKDWHQjAe I4tw57JX6RvPX7ilI6O71FQEm0b5vVGeWLvilVL/Bg4PpJOD3L8in1IL1pcv+M2jLKB7 HmQoTYJJP38rCMZSZzjim8oJGusOuAAjhJaEXfc82XsBA3A/9nsr0hdycxNuLgSbtE4H +4OQ== X-Gm-Message-State: AOJu0YzDkbDY2exBe9Yk9N0unIiheR9fR12p9ZmA3X8tUkzSxUV2DgFO HPI6kcmZXBB28Vlv3vJj3obxsxUuy/WPoemajXw7lw== 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-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Thu, 02 Nov 2023 11:34:56 -0700 (PDT) > > > 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.