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 3CA56C4332F for ; Thu, 14 Dec 2023 18:58:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BDA596B01F4; Thu, 14 Dec 2023 13:58:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B8AA56B01F5; Thu, 14 Dec 2023 13:58:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A51AF6B01F9; Thu, 14 Dec 2023 13:58:09 -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 96F606B01F4 for ; Thu, 14 Dec 2023 13:58:09 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5DA661A040F for ; Thu, 14 Dec 2023 18:58:09 +0000 (UTC) X-FDA: 81566333898.08.10F0351 Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) by imf06.hostedemail.com (Postfix) with ESMTP id 892C118001C for ; Thu, 14 Dec 2023 18:58:07 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=V2xbwNRU; dmarc=none; spf=pass (imf06.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.173 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=1702580287; 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=kbRUvh91lczsHsuPwuxCeC//+oO/v5EJyyqmBzZyIng=; b=5QGULD+l4BgWOtWOYvNYGF7AnEpjbYG41SgLCN4wGMPkjcn7an10Ef5+6jtIiksVyVnCN0 3fGEKKi3JmY5IjXdvUSLZcF2vp3VycuLK9tH6aUxNS2CjRstg/Nq0MzRAjz7KOD30CkVdn XwVBpN2OvomKqkaYepDL7bmR4+QHunw= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=V2xbwNRU; dmarc=none; spf=pass (imf06.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.173 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702580287; a=rsa-sha256; cv=none; b=5vlJFP2z6zs05CCvBoMt0mkNGSYSBkeHRO3ILGos+mc2PhQnrp8T6LulQVytz0qHNVirQe S0nsAfbTsTOgECXDjSvlqCZidMWE0Y9hnb+wWRanMktBX2Mq8/hjL6PgWkH7pEQMFvnIYk ybCFMcsQbGcM7IHUJ1uAZvFzhLcnpKg= Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-425a3cdbda9so7992331cf.1 for ; Thu, 14 Dec 2023 10:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1702580286; x=1703185086; 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=kbRUvh91lczsHsuPwuxCeC//+oO/v5EJyyqmBzZyIng=; b=V2xbwNRU8lT+cuaeSdPbdth1dTVne0Hfzoq4rgAwWwkIuVR6zfAqm7W8BHkuTfh5PW exdlW0ig5rudC1Hpq/p5T3aWnkQocGa/BVoto6B+V/oxL+wenoQ2VEJvuh3APXoLtaWI 21wUpwdI75xXqVoz2WWrwSy1Jcm3qWNIPC7/Gj2HOvi6Cy2hbtMinMVL5hNj/Lvb1eWt 7XuYbjPA8R1QeuR36ZMDbLqQfKCFeuNzQ24hzvTiwlVrS2aLiSUCvl2Tblh5KIG83Tw0 K3Fz2XlRRD3HPQS5YLJIcUc92EtRyxNKNk91BByR3qRhYhbrH5scLsFLFukjUifofG/C xjwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702580286; x=1703185086; 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=kbRUvh91lczsHsuPwuxCeC//+oO/v5EJyyqmBzZyIng=; b=qZWgJ3zQZaY8VC9t6LCnCAEZNFARo0dgbVRBHambM42HFe+XF6SW2QA5nd2bNHbjqV VvukB1DRl5xPO0YYwcOVSHli/QEppnSRljyFy10ZYgPb9aQoq7SAe81XKc+4wCIs+tne JsXW2/NRkHcacXdWjazMOOw8osgpUEq4cHefWMeJjeozVCUV6FEeS3KgCM1wbAIDd6lO GshNZj2ZCoGAImDqtPHKXuJI1ccOlo3E7U/+NIfx/hQEYiwlmPoXlDVutc/cC4eJLvZ7 35VJzOHJo///HL26v8ZHnmJG9blxyDQJm6wT7MlC3zCS2XxsAGDRSWfT5Wavaf3+JepY 5DTg== X-Gm-Message-State: AOJu0Yxh+49m7ovoyxAx7iKZQmo3y2RQDbSS6uWBjX435ad516RfSom9 iJ/7uo26YChcqNRdug3YB0a4pUeSmquoEmVBwmmYbA== X-Google-Smtp-Source: AGHT+IHA88EdWJi6YEaUjD/G5Alic42eMo76cOAWFc0QtX1OeP9Hoaw7Y53/0yZMK7MTS4ytkjNfaQ4yEVSKsvmYBtg= X-Received: by 2002:ac8:5792:0:b0:425:8b1b:a286 with SMTP id v18-20020ac85792000000b004258b1ba286mr18152227qta.39.1702580286617; Thu, 14 Dec 2023 10:58:06 -0800 (PST) MIME-Version: 1.0 References: <20231211154644.4103495-1-pasha.tatashin@soleen.com> <3d415ab4-e8c7-7e72-0379-952370612bdd@google.com> In-Reply-To: <3d415ab4-e8c7-7e72-0379-952370612bdd@google.com> From: Pasha Tatashin Date: Thu, 14 Dec 2023 13:57:30 -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: 75bx7z4cb5nokxktjf6n6wcnyzqhhkxr X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 892C118001C X-HE-Tag: 1702580287-253276 X-HE-Meta: U2FsdGVkX1+jJjv7Sk333nVsKvXwdz/YNK0ANlX3XiHN2uOwGhBTj4DXw8bnh/SCfIgBGC9N9k59eAd190wVsESy/NydUGbWCynuL+StZDV19nM9U7wYd2S82O/WvRFYHQyu3+bx16AWG8rGuYcFzhQp47+2x1yoKa0NoHLuQ4M7wAkC+Az8CY4RPxQ0MLTgGvIrO21PCwYS+qqA72snd+fQFFYRRYcSG9AlTVICfh58CZdkK7MqHwMkE7fxTWvoZmLRYHWAhBkoVtt2YcJUK4TB3PWqeNEJSBNAZcWBjja2mChYvMGDgOf99h1oXb9TPyOczhoRMcPcJIGrmwEzpnFgWHNsaghMpx1TtMjzfiK1tDWhxfRIre8ZC3vARGgWa0B5gPmJvd+8Vs8i9rin+SrvlcE/FBOuabDeG8US+LxhcSCiKH0M9P8fKFdiU//h0GOR96nCl0IIXSfqykfUmBgAomMQczFrevMz7JObqyb5w3R7GawEvjqjb6CBqQqDqaoAgv7rig3DAoLsYe++AH6roSg3WKcPU0GxXOJyQvhvoaG7+/lUHy8IOV8afBaNyvhKfI3v2kIao1rU1DQ72f7H6uFPlz2mbhbBu5VeWdScIqdTGjL/CXEtdpJDAGgturo9fzR0kHtIrk5fZXG0wp/cjhVEaq9hndBE42ArPhdJSAQbk4XdSnnRINol86DpBSQbWOlILi6Ld/qmFOsihpoc2m5bPJ7KTduePG1K/8BYi9YEMmCbAicvkyfwsdnWYekNgxa1mT9GBfuLhmt5SL2NDOGQ66Of+RmvcVnU6E/r34wbKD6dPN2XtzLwYWvFitatEcRR2LSS5JTo0Gd2JWWNwB1iH0dWhw6pSOb5zGUxHBqBXnReP9PJtmCXaaYVAgJOXvq2Ov7J0YWhU+KMSNSEEMXK/sbV8/wBgbjChg4+rNbDwkQVk/wEwM1sHg2YQgGCTq7nm+9PlzERXHZ SL3vZXau XmzA22CSNVxTR/V0YsinOHHeXfQjQSCSZuMkHDR5tlOb3NfCdCGbJRyiMCg++DICrG0lAr0myoVWdHi+7Z+tiRqnbFdpqw73ftTJDRCV0gCJ6euSe9dh626UZmTinr3ADICjGrypeTAUg4Y5cHTxMzukOM7X9xn1dq3E7dblHtfUFE2upVKViU/LFL456kCwN/EA+nihkn7iLSLDMWYhBApAfZNdn4eyOxqRQ X-Bogosity: Ham, tests=bogofilter, spamicity=0.010029, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi David, Thank you for taking a look at this patch, my replies below. On Thu, Dec 14, 2023 at 12:52=E2=80=AFPM David Rientjes wrote: > > On Mon, 11 Dec 2023, Pasha Tatashin wrote: > > > Whenever a new fields are added one of the following: node_stat_item > > numa_stat_item zone_stat_item, the /sys/devices/system/node/nodeX/vmsta= t > > 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. > /sys/devices/system/node/nodeX/vmstat has been documented as a stable ABI > in Linux for 13 years. > > That said, the contents of the file has not been documented so I assume > it's "whatever stats make sense for the current implementation of the > Linux VM". > > > Also, once a field is exported via vmstat it is hard to remove it as > > there could be user applications that rely on this field. This is why > > we still cary "nr_unstable 0" in /proc/vmstat that is not used. > > > > Implementations change over time, so this would be expected. > > I'm assuming, but perhaps incorrectly, that userspace won't crash if > nr_unstable just don't appear anymore. That whoever is using it would > just assume that it's zero if it doesn't appear. > > So I think we need to answer the question of: are the *contents* of files > like vmstat that are heavily dependent on implementation level details > really part of a stable ABI that people can expect will carry on forever? I agree, but that is outside of the scope of this patch. The intent of this patch is to keep the existing interfaces, and only prevents future auto expansion of vmstat files. In the future, we work on documenting the existing vmstat interfaces, and perhaps cleaning-up them when possible. > > Also, since vmstat is auto-expanded the fields are not documented, so > > users do not know whether they are counted in bytes/kilobytes/pages, > > and the exact meaning of these fields. > > > > I think that's actually intended since there can also be ones that are > event counters. I don't think any fields in vmstat are intended to be > long-term sacred stable ABIs. Right, but we already carry fields i.e nr_unstable that are hardcoded, but were removed from the kernel otherwise. Thank you, Pasha