Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp4178333rdb; Thu, 28 Dec 2023 12:52:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IEBXTQXf73k6n5v4djY3+Q+9RPwas8qp4zasNeoYe2AlDCSj6ZG0Yu3y6fyBtQNG7nFF9rL X-Received: by 2002:a05:6358:9183:b0:174:ef00:94ed with SMTP id j3-20020a056358918300b00174ef0094edmr8427370rwa.2.1703796762558; Thu, 28 Dec 2023 12:52:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703796762; cv=none; d=google.com; s=arc-20160816; b=bCvtPNy8O7iFrGFMxyjGUZoKy07urUy/+8KG1FaFoklxGa71vqjfL6jbx69iNR1DVH AXZS4TIWbIRGcHOFBC68TTvsU7YLS2B0b1emuRx5ijpEjtJQJBnBURvStjPKdnNvdwhy MV1qIwd5msEF/X8nKGoBlXcBYF+feCGsyrQAB0lNF4D5WC09mXA1hDAb8Gi9M+BCi3ap 7PfPzH0E7bVNDTbd4XhT+StNaKWHhK/ISl3Qvjn4C5wH09m+od+nlh6iRsIJF1TMNdln eT2yHcsbMNPwLz/xAlCdJdqOu2/S/FJvcl2/d3LhGbsd80W5tLSPcwGsNlvx1nC1nIs0 swFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:in-reply-to:subject:cc:to:from:date :dkim-signature; bh=S788tp3IyJJGZzIwxLHgTA4XtDw+UIahU/ujGgekUjs=; fh=FQathK3rCPwN57EFIIT/R3L+xWbeelBDK/k5oDZqzmo=; b=ALp/7/Pq6NTCOD6j8oERImqPQU0QvN9O+ce8UIBvp1X8wIxxdM4X3o7F+VEigt2pGY hSIRFLAsC1wkeuqAPqMzmtTeHYugq8tTxD7gZm+32ASJhHiEQfbTTzNS4uVKB2sUf5Lz p3x3xQH4M8LyO3ZVHTTr9LSyYGN5zgCZdIeP85P9G2VkayZN9v5mJdLKD2qifCpu+/2s /GBaf9Uk8+0PuJu1rayqNrhA00lEnCmd3T6RCuaoUS/ISeUxz8CEQOCz6IBLA3a5UPnF wDhvQmDWd0rnYeqHVVi6wSiUb6QS2usc5x0rCqxjQo8CxQtbV01OcbftRaem8PZJ/rgn Fpcg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=4VIuaT64; spf=pass (google.com: domain of linux-kernel+bounces-12857-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-12857-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id p11-20020aa79e8b000000b006d996c55d33si10369217pfq.389.2023.12.28.12.52.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Dec 2023 12:52:42 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-12857-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=4VIuaT64; spf=pass (google.com: domain of linux-kernel+bounces-12857-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-12857-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 388D1284D75 for ; Thu, 28 Dec 2023 20:52:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7051C10948; Thu, 28 Dec 2023 20:52:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="4VIuaT64" X-Original-To: linux-kernel@vger.kernel.org Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6D9B210947 for ; Thu, 28 Dec 2023 20:52:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-1d3ea8d0f9dso698455ad.1 for ; Thu, 28 Dec 2023 12:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1703796754; x=1704401554; darn=vger.kernel.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=S788tp3IyJJGZzIwxLHgTA4XtDw+UIahU/ujGgekUjs=; b=4VIuaT64H1q3F/1QIroidqb8/tFm6CxIPexsb1EpqvyOAILt46luAZClmdgwl/r3ko MoQxhQAo5EnwYZ6pPLg0PDj4D+STFxqi8cXpLHEEu+NZg3rM3o2i90bBPwTHi8qiBmj+ 6xkL2NNvF4QTiqf7fyi3K/3dltVEvvgUeM+TPmioPiqLz1EjU0pVr5Le14Mmg56yEyEl Ec6vnTsGC1v6b4KVDoV6+VSzdziqZ0q6lOkzNCMInaLMXObEdmjNY1+MV9fwCMhNCwU/ 4bp4rmuq+URqic1tHzu6EOpFBwPk0IDR5OR0sRvEwZmcJ5MVMZXDqScYwINZ0jxLV9yG vf+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703796754; x=1704401554; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=S788tp3IyJJGZzIwxLHgTA4XtDw+UIahU/ujGgekUjs=; b=W9dJEClVWy+efYWqvoLawij1olCpP3+tQ6KiBIV6bq1AXga0Di+T209ykh7i0xHv28 KONUWve7sDnpj4oi4q3EcOT2l1FeoFxN9XOY3j3Uv9EKktkHceoWVpOQmMIoTTp0rx8w QA8b6GU2JLPePI4R/CT6cFtyS7ZhIgk4e9RIV9XpWPO9LfHV74QgxDrgCpkwxGtxwOYL GsDmgqGjOzCMrQIYKLGMWWjlVEGI7h2LRqo3AVWbnTTbWQtrUeMwJgG0qsWPuPlIaM9A hx7f68a3pA8TM9hG2IQ6+tjQB0ptGVIJ1cHHsD+Hyt3z+0Er1tftSNRmatayz6uHC8Ke /D6Q== X-Gm-Message-State: AOJu0YyPDFFrbY5BHOyxD0BEp4njNCwphZ2lDhkQQpad+Ka7One+JVbj hebmG3kdHorGlm3XWw9nvKz9Yrposgoi X-Received: by 2002:a17:902:ce85:b0:1d0:a45c:202 with SMTP id f5-20020a170902ce8500b001d0a45c0202mr771128plg.24.1703796753327; Thu, 28 Dec 2023 12:52:33 -0800 (PST) Received: from [2620:0:1008:15:5eb6:dfb2:ff4b:8b64] ([2620:0:1008:15:5eb6:dfb2:ff4b:8b64]) by smtp.gmail.com with ESMTPSA id ju22-20020a170903429600b001d1cd7e4acesm14344261plb.68.2023.12.28.12.52.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Dec 2023 12:52:32 -0800 (PST) Date: Thu, 28 Dec 2023 12:52:32 -0800 (PST) From: David Rientjes To: Greg Kroah-Hartman cc: Pasha Tatashin , Linus Torvalds , rafael@kernel.org, Andrew Morton , surenb@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, souravpanda@google.com Subject: Re: Sysfs one-value-per-file (was Re: [PATCH] vmstat: don't auto expand the sysfs files) In-Reply-To: <2023122824-washout-shrubs-1d6d@gregkh> Message-ID: <829410ca-1454-968e-b724-0ef0bfbca5cc@google.com> References: <20231211154644.4103495-1-pasha.tatashin@soleen.com> <3d415ab4-e8c7-7e72-0379-952370612bdd@google.com> <13e5fbd4-d84d-faba-47f1-d0024d2c572d@google.com> <2023122824-washout-shrubs-1d6d@gregkh> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII On Thu, 28 Dec 2023, Greg Kroah-Hartman wrote: > > I'd argue that the ship on the "sysfs one-value-per-file rule" has sailed > > for long-standing use cases where either (1) switching is just not > > possible or (2) switching would be an undue burden to the user. > > > > An example of (1) would be THP enablement and defrag options: > > > > $ grep . /sys/kernel/mm/transparent_hugepage/{defrag,enabled,shmem_enabled} > > /sys/kernel/mm/transparent_hugepage/defrag:always defer defer+madvise [madvise] never > > /sys/kernel/mm/transparent_hugepage/enabled:[always] madvise never > > /sys/kernel/mm/transparent_hugepage/shmem_enabled:always within_size advise [never] deny force > > > > This convention isn't going to change. We're not going to suddenly add a > > new enablement or defrag option that can only be set in a newly added > > file that is one-value-per-file. > > > > THP was obviously introduced before any sysfs "one-value-per-file rule" > > No, the rule has been there since "day one" for sysfs, this file snuck > in much later with no one noticing it against the "rules" and I've been > complaining about it every time someone tries to add a new field to it > that I notice. > Ah, gotcha, thanks. I had assumed that the push for one-value-per-file started after thp, and perhaps even because of thp :) I have to admit that whenever I log into a new server type one of the first things I do is $ cat /sys/devices/system/node/node*/distance and that table just makes intuitive sense. If we were to go back in time and reimplement that as one-value-per-file, I'd just assume that many userspace implementations would just need to read 64 different files to structure it into the same exact table. On the other hand, I have wished countless times that the thp settings would have actually been one-value-per-file from the start.