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 E9CDDC46CD3 for ; Tue, 26 Dec 2023 17:27:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7016E6B0075; Tue, 26 Dec 2023 12:27:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B0526B007B; Tue, 26 Dec 2023 12:27:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 577C76B007D; Tue, 26 Dec 2023 12:27:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 46E356B0075 for ; Tue, 26 Dec 2023 12:27:07 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0D93F805D2 for ; Tue, 26 Dec 2023 17:27:07 +0000 (UTC) X-FDA: 81609650094.21.A6F5726 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf18.hostedemail.com (Postfix) with ESMTP id 3C6411C0026 for ; Tue, 26 Dec 2023 17:27:05 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=WfujGbnd; dmarc=none; spf=pass (imf18.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.169 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=1703611625; 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=qF6xW1bdeiaI+KNkFjHq71eA86SN7AHEznnIaUPRnMI=; b=MpVXV/ZboH9YTE/V6Zl+WYax7zT3g8d6N0HZT8t7ido9vF4j31LvVxElcdbIBryYPXN0Bt qmgd/wdp5UhbUnhJ1NZnQPGzFsgjSeQnOWJQhAoF5PTqti0Q5JIkvH5o5LpLmPXbrh3PT8 c9UsrjoijIBojyM5VZf51BO+QV4Ml+8= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=WfujGbnd; dmarc=none; spf=pass (imf18.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703611625; a=rsa-sha256; cv=none; b=AklM9Gwic+KFAgCyDO7PSqvmjXRCqZFP09vRlJ/+qrNP5pLRW7XA9WN2TOPfU2bhqjoqOt Nh6M4LfmRi6Lz2tuqwpDRrf/VGtUWqgsFECRTGNn1HnamyOceDzcI9CUASx2Sh0EDXU30E vaSxWBdplgt3p2UE3MvW2m3Nk5v5DxQ= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-42786514fe6so42779041cf.0 for ; Tue, 26 Dec 2023 09:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1703611624; x=1704216424; 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=qF6xW1bdeiaI+KNkFjHq71eA86SN7AHEznnIaUPRnMI=; b=WfujGbndjTeRjN5XnfTlkNbESwS7oiiR0gdsA4CaZyw+P9/ZoetcLxfYm9egAAl9uo CN4ke+PZcAhCd8pb1x8SA0p6lyP6AhJkIDeNE9EXsNhqZKHT4IjOornPSakswiGWfJ33 iIZ3kz0v0TGqmy8MlM7VaOpm4ybXwqChJWRk0Y531FgoH1h1Jx6y+uLpYCqy12M3eKDG GvPFWL2VImktPlyBk9TpIM6GGDuxRVh001Jaqc+6SvJ5xAzT/h6syLmER0iRj65e0r26 63H9QkKP8kOkomhErCk0W4H39dtSEfCMQT44kuvBsm/FU3gi0EOsGqH0VuAOR76SMYJc v+Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703611624; x=1704216424; 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=qF6xW1bdeiaI+KNkFjHq71eA86SN7AHEznnIaUPRnMI=; b=wmvfCT+quxFIc5k/xICuEU6aWyK20nW483Uf8WJsVr20ME9wk6fa8Di/NipIpSkt4l Km0W+veOZd/wJuBL6uZiC6FZQvYHspiATTxgOE9n8MOzt7fIe31A/4ck9JCDaIGoAEam M6cbMMoCU6DRB9EwJxdScUoJowtmUGlomu9yyraxEFBQV7yRYjtXeDKmVvh6y2laa3mD zICEWDoNTHxTXzMKAxZPkCb+OIX2m45RLocKcTJvIXn/czRDk5lEPmuEvUdC5gABlHgj Yuoz7HQIdcJS1YZ+ilJFIcaxnOc8qM9kH3Zij7dgCHa1tkioCZU32WjB+vFM8ei1zcgb ifLA== X-Gm-Message-State: AOJu0YwqxTK8kuJYuNlmoawYFzhEUHAjQCHey3uiTeyVAtv0PyNR+pSL 2itLfO5Yiln376fCt0bGZyGUSm3id8KVZGNVfn4OBfu18p+nZEWCTbtc7V+X9/4= X-Google-Smtp-Source: AGHT+IH6JuPA8UpnDuV4pxNWx2qfVnI+AAQgcgG4cJ+LVKws3skpVkqpE1GlHsFAzqe0zp/iS42nIMznuVlXnxn82Uk= X-Received: by 2002:a05:622a:11d1:b0:427:a316:a26a with SMTP id n17-20020a05622a11d100b00427a316a26amr11771992qtk.69.1703611624440; Tue, 26 Dec 2023 09:27:04 -0800 (PST) MIME-Version: 1.0 References: <20231211154644.4103495-1-pasha.tatashin@soleen.com> <3d415ab4-e8c7-7e72-0379-952370612bdd@google.com> In-Reply-To: From: Pasha Tatashin Date: Tue, 26 Dec 2023 12:26:27 -0500 Message-ID: Subject: Re: [PATCH] vmstat: don't auto expand the sysfs files To: David Rientjes Cc: gregkh@linuxfoundation.org, rafael@kernel.org, akpm@linux-foundation.org, surenb@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, souravpanda@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: 5t954k99r7ohqiy3q3os7g71za5q7paa X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3C6411C0026 X-HE-Tag: 1703611625-154471 X-HE-Meta: U2FsdGVkX1+kCUCh1MFgNUzPV1slrg/baqffnugyTIDbkicISyOys0nIVL3H8W6ZjjDCvVjQjlQD5HkN8M5GHMEdJvOiN4c8YtD91BTdXdiCRucHgBJeJd5uZbB2awBZET60727iL3tLMxHTup08Wor8sc/fBYyZHEeUWrsWVGoaqL/wv03vQXk1fGoQTYzMLKxueIEQHf7rEO4t+Bk96mSvfyHbTQ/1IPEATIdu+ZaTe0IGkTenKe6in3TOvmk1oAtuUeVf/fSBTRQZyQmuOAzTC4Vx+zOXjXoGjDGEVI6z5qO4nD+FVQbVRWLqHTXkvanNOj94+ACgAHZ2GTmY9ldfFhLVowF3tjIvh2P+eO4L+I9YBSdGiVxIZco8TzH/WUXPQG3vB0F3jswBuoQ7Y6BfE3w8YmPdZA2GuHOA3wAol2uQWSsSJDAgfPtK0C+EIaxviwavuQ40u/SdIaeBolJwkcCAQoRXmzcn3UMbsm7a7Q2lAwkdOWyzhFLpCyVjUQBShbV/yElApsO2fzkNx3Ce0Ff9RfNZrOkDJgLyfHE5eB+4i9Kk0XMMZuaos9wmXfye36tpjebqkouYsXdC11bHtpcFbo5vEdFaqnXaNnItdVZ1SCPSkuHMfsiV8es/Ln5aumEMMsz9XAu+WGOaH9mXYyW+6GbN/JfuwDkN87YMFmQ6s8l6AIiAx3UYfnR/Xh6KwXRDgJHT0ccSyqYTxzTAlHbfsWBSlL9F2EMllyEqPg7lIvtgJmgtH8p/kAuv2m8d5gUOVgq8C3JbCvzsd1mzIKvjECMJ5x/mJaxq1JJBI2ThOfDQb3/Yyu21qGAc4Vq/X4xJubkKkS3f84qr3P2IXn8N+R6X7XREaJUA4tmMnWyt+E22+r2Nc/RaQbSInJN2jgce/VQqJhC6EXMOZd45KetVjnDAx8k4hf07Jh40qaPacbhbK2gaOrpyNkt1HXyU6eJzIJ+YA8j6c6l jXcDiQoJ r43OEueKnB15Iy3rXEeEDXQ3f37ACwPnUpd/SqGe1hcFDL9pD7CbWW1PQ9c6o1qTqbYWi2H7x+m/+/zNjMDihg+exh05x1SCzBSzyvYZu7RP7Lz6Pdsjgk7VvkjjSnsAmS+ieh/YJCvJaQQEZ+ctTvsrtWsV19h9jJZ+kkJSJgBbRyHCRLeLG2iPUwopSayQRZ1SEA7h4t0EQPHIcjqwdG4LRxQpRBe/SPyaN X-Bogosity: Ham, tests=bogofilter, spamicity=0.000264, 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 Sun, Dec 24, 2023 at 4:26=E2=80=AFPM David Rientjes wrote: > > On Thu, 14 Dec 2023, Pasha Tatashin wrote: > > > > > Whenever a new fields are added one of the following: node_stat_ite= m > > > > numa_stat_item zone_stat_item, the /sys/devices/system/node/nodeX/v= mstat > > > > files are auto expanded. > > > > > > > > This is a problem, as sysfs files should be only one value per file= . > > > > > > Does this patch address the one-value-per-file issue? (I think that = ship > > > has sailed for vmstat.) > > > > That ship has sailed for vmstat, this patch addresses what was asked > > by GregKH: not to add new values to vmstat, as not to make the > > existing problem even worse. The sysfs file system has a one page > > limit per file. The developers will decide how to export the new items > > added to node_stat, numa_stat, zone_stat individually. Each new item > > can be exported in its own files, and must have its own documentation > > about interface stability, value meaning, and expectations when the > > stat file is absent. > > > > As of at least 6.5, /proc/vmstat is a strict superset of the per-node > vmstat. Why is that a problem? The intent of this series is to stop auto expanding /sys/devices/system/node/nodeX/vmstat as sysfs should only be one value per file, and the task is not to make things worse. /proc/vmstat is mostly ok, however we might not need to auto expand it as well, to avoid situations where removing a field becomes a problem, and we have to keep it in the file forever, like what we do with nr_unstable. > There's great benefit to being able to use the sample implementations to > parse either /proc/vmstat *or* the per-node vmstat and without needing to > read the per-node vmstat plus some new set of sysfs files that are > one-value-per-file. The per-node vmstat will always be multiple values, > in fact it's a key value pair. Yes, but that file is already large, and soon can overflow a page size, instead of converting it to a binary format, let's add new items as one item per-file. > I have to think that doing anything else for vmstat is just adding > complexity (like this patch) and actually making it *harder* on userspace > to read the data it needs. > > Yes, the per-node vmstat likely shouldn't be in sysfs at all but it > appears to have been added there 13+ years ago because it was a convenien= t > place to add a per-node variant. That's not ideal, but owell. It is up-to GregKH who requested this change. Greg, specifically requested not to add new fields into per-node vmstat, and we are adding new fields with per-page metadata series, and IOMMU accounting series as these files are auto-expanded without this series. Pasha