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 0166CC48BC3 for ; Tue, 20 Feb 2024 08:50:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 829C86B0081; Tue, 20 Feb 2024 03:50:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DA476B0082; Tue, 20 Feb 2024 03:50:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C9936B0083; Tue, 20 Feb 2024 03:50:15 -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 5A1DB6B0081 for ; Tue, 20 Feb 2024 03:50:15 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 203471205F9 for ; Tue, 20 Feb 2024 08:50:15 +0000 (UTC) X-FDA: 81811560390.04.CBB8EE6 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf16.hostedemail.com (Postfix) with ESMTP id 483FB180016 for ; Tue, 20 Feb 2024 08:50:13 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=h+VqC9eQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of fangzheng.zhang1003@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=fangzheng.zhang1003@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708419013; 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=t15t0QA8PUUprA9RZMeoEMSHHE4KRxpyRH362kM2s2k=; b=pt9+9yVveTjUfrMqRBWgHBn0HFGj7AaDHG9YcNDW6Gd2etWdSvS63wd2isACwuPtRnzjvu b7cuejIK/igJO0FwjK6PhQzNFaGcCCqNvFbr4/F0FHfaU5i7l10GKA2yL2OX2DjpSjE5LD 1r3yNoc/frPfK/pwMYm10IHH+h+3y/Y= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=h+VqC9eQ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of fangzheng.zhang1003@gmail.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=fangzheng.zhang1003@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708419013; a=rsa-sha256; cv=none; b=o+cgaISXIaeM+dQlO6UIEOrG/Tp7KZVvZTbT2zMPVlRDMjkgInNuKpy3pf2pC/dNI4cAm/ 3DxRJE+anHkSSoVk6hlV5rCiEQvzgfcyXM7ljaT2FmxKRbYEmdgWjR0VBhx9WQb6kQZWy2 pTKVgvcU+vFNbQkhmsnikSUvlLYpEV0= Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-5112bd13a4fso6705109e87.0 for ; Tue, 20 Feb 2024 00:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708419011; x=1709023811; 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=t15t0QA8PUUprA9RZMeoEMSHHE4KRxpyRH362kM2s2k=; b=h+VqC9eQKRwM7H7TWRSMbIsVCuF0QeqhGxX7QFwv0VbIqyVc6UwutGykqCv22F8G/k 8Yj/8rXrzM3q7bd6DolQVef3DclSVEY0M/qPLwp9r8+tRA8acGUxsome06P1JdXEc/P1 Zdz8dNHlm8TDQHm4UPOdTNhF3P270PlpvdGgsb4Y+YhpBswCgZsOrHnhcdBPvbtvsZsv Vxbs87qzLfPE4h++AJEg1jkl87I3Uu1u9o/2jd+MPZH2p8LEj81wtI69rXqTFAl2+i/D F+HDBuaCNc5EWq9yG6QRW/p6NvUaUg/QLD2Obcnrc+mUfl9Z8W4DiWPXDailo1AV3wQ1 SGkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708419011; x=1709023811; 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=t15t0QA8PUUprA9RZMeoEMSHHE4KRxpyRH362kM2s2k=; b=IRf7a9gXtDJtu8Hv72qRr5gr0ER3Hx/ONYp6jMvylDhuCQtEnFI8/SdyevWmpdxm53 t5uY1wwcaNSBodO/dE/CJBxrXpSwzf21W5ioTuIjw9hzSYIhTLEDBzij9h5sNpFvXZeM Xe0hyEXSEvYPkHEZXjJnuZe+RtBC4lb8D5x2V9WP3VK8NpI5tE8CEsNT9Uq1FvEJ7v/K lDoVWqQwh2NBhbNUJNQMS5urVqU0H+YPjalJNMFjs4I9hmkNuzdppsWW6thgWjWLahjj q3GnNm9JnNXOKela7tKOSPI+kF1n3PbSr1m1dvBPAE1mA/QpUdTapU9gjv8pd3DwfyCJ 6grg== X-Forwarded-Encrypted: i=1; AJvYcCUPEYE4V6CL5i4bHvlMzTsIY8KpgMvTNESTuri9/lJq2MVTiKvgCX8ax6Z/qBvf1T01Z/JVXU/yadmCbAuKGdYIzT4= X-Gm-Message-State: AOJu0Yz2FQpnVnnjBa7ebtKPssp4wFJ50XIwZpUgvFbcA/n9WAakwFcY aTSwIGCQ1Ipm1IjUJzrjPQYOqJTzWHxNgEak4sfGjRVRzHLKr53g/xpu9uOuSrBPnll+bjZdNHm h3GxW+9ZlTv+cmD4JU8DkYxPTOA== X-Google-Smtp-Source: AGHT+IGSrY3qaVh89MY2zmF9/3vB9Lqtwk0TAXP32s03QoePEzUbbI6OHGKgOJkgEt4RI1ZdDfVfxT7iFF2pb/OSiL0= X-Received: by 2002:ac2:4a81:0:b0:512:bead:d1a0 with SMTP id l1-20020ac24a81000000b00512beadd1a0mr759189lfp.14.1708419011168; Tue, 20 Feb 2024 00:50:11 -0800 (PST) MIME-Version: 1.0 References: <20240219031911.10372-1-fangzheng.zhang@unisoc.com> <20240219031911.10372-3-fangzheng.zhang@unisoc.com> <4591b2b3-398f-402e-b21d-55b244f05a2e@suse.cz> In-Reply-To: <4591b2b3-398f-402e-b21d-55b244f05a2e@suse.cz> From: zhang fangzheng Date: Tue, 20 Feb 2024 16:49:59 +0800 Message-ID: Subject: Re: [PATCH V2 2/2] Documentation: filesystems: introduce proc/slabinfo to users To: Vlastimil Babka Cc: Matthew Wilcox , Fangzheng Zhang , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Greg KH , linux-mm@kvack.org, linux-kernel@vger.kernel.org, tkjos@google.com, Yuming Han , Chunyan Zhang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: qrabdwm86jknbhs8ras4n6f57z99e4ak X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 483FB180016 X-HE-Tag: 1708419013-432285 X-HE-Meta: U2FsdGVkX1/l7FN19hc9CwYc4Y3XJspxGF2WfuWryKBFwm/SGEsgA0jRP6Me/VwSJFFqdjXV1n7gmNiPdtTK6Y/Qc9eiTX4BYPJGd/ivTIgjUUnGbsom1kNxlS1CRPE2o2L9GO+3EB95D7FXpPX4s8tMh51oikvBcoMrR/FW80596WoH62WPV1zevJaQrZR65ZdOujT3AtngGd94tAzv0xwBpcAPG9xyLwEz2AXBizjJS8sSrqFI1a8fOWR+j4LKRUneEyG68LEtqDPyX/E0KQbVMH1uGxVAfmx44qXQ6bFQLqpWbvtj5yHlbY9p9LmiWGA9pzHcgr0gwEG/a0ronWYchQOqrBfcfaW6rxQSwoR3SMvTxmzvvC4134hEyoVssaBAzjuhRbZtcdEh5HVOkgV6uBBtsji9pmyvkX8a/xZbVhvW07fK6EWK8x+h23VyKk5uzYSLaHkp75L89glHgu7ajXscK7jy23+fiFWL1GoDIiWas6GtCSYce+gkGi++yEU6gQIhdg5fDofj77dpqbkcNpYv4EYhBuuYfGi7hau1Di/dXOFr0kahZO1x/d84gn3oQqJPzubYTtKSK88/j1yRGWrEfiM2Ht8jisNZDxKCfwNsXluH4XxEcNbosdLwMS8E3e32gKfEeftCwCl7Ydmcx0krjbgTN3io5ZGV+/jXbIma0E3ICYPKeI/zTqydwzb7qAMkixpo24PYenzG5oPcAr8YupjzzObdRAUkSxn7ZO4ZlZ1tyL8a63kgslYHBDXwpZn4z5FidCGmKxlMbJf/JA8uJutXS+EwZU67xN6JkDweYW2rCfn8c3CC0n8pjLuwufip7fm82twHIuVkg9p0chwvqiU5a7OLKx8JfJPHXsxp8jnMXW6U/bS05G6YpT/6WJ7gAtuaK6s4l3toVfIeAb5+YlLvLIO7N4RLCrwZ3OHLCW8RXm58IULxtZK6d9RNa2pAViasYR2bYsA 2kV4Fft0 4x4UgXIbdUtJIz3zwspEgek+ez5PkzYYMftTnFse/Q7/LF+9/2bRJAUNtWbmLA8kC9Rx6bO9ktnTiMtekzqX15w4PxHY4i9IuYTBYvHphZQ6rY2pj7RjD9l7UUjDsUNsin25WF5wZmj3lfVQ= 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: On Mon, Feb 19, 2024 at 4:09=E2=80=AFPM Vlastimil Babka wr= ote: > > On 2/19/24 07:23, zhang fangzheng wrote: > > On Mon, Feb 19, 2024 at 12:24=E2=80=AFPM Matthew Wilcox wrote: > >> > >> On Mon, Feb 19, 2024 at 11:19:11AM +0800, Fangzheng Zhang wrote: > >> > +Note, comes from the collected results in the file > >> > +/sys/kernel/slab/$cache/reclaim_account. Next, we will mark /proc/s= labinfo > >> > +as deprecated and recommend the use of either sysfs directly or > >> > +use of the "slabinfo" tool that we have been providing in linux/too= ls/mm. > >> > >> Wait, so you're going to all of the trouble of changing the format of > >> slabinfo (with the associated costs of updating every tool that curren= tly > >> parses it), only to recommend that we stop using it and start using > >> tools/mm/slabinfo instead? > >> > > Hi, > > > The initial purpose was to obtain the type of each slab through > > a simple command 'cat proc/slabinfo'. So here, my intention is not to > > update all slabinfo-related tools for the time being, but to modify > > the version number of proc/slabinfo and further display the results > > of using the command. > > I'm not sure you understand the concern. There are existing consumers of > /proc/slabinfo, that might become broken by patch 1/2. We don't even know > them all, they might not be all opensource etc. So we can't even make sur= e > all of them are updated. What can happen after patch 1/2: > - they keep working and ignore the new column (good) > - they include a version check and notice a new unsupported version and > refuse to work > - confused by the new column they start throwing error, or report wrong > stats (that's worse) > I generally understand your concerns about modifying patch 1/2. But judging from my modifications, this worry does not seem to be valid. Because the =E2=80=9C/proc/slabinfo=E2=80=9D is not used in related slabinf= o debugging tools (such as tools/mm/slabinfo), but "/sys/kernel/slab//" (in Documentation/mm/slub.rst) or "/ sys/kernel/debug/slab" (in tools/mm/slabinfo.c). Furthermore, the current modification only involves optimizing the output of proc/slabinfo, and does not modify the struct slabinfo or struct kmem_c= ache. So there is no need to adapt other modifications. > >> How about we simply do nothing? > > Agreed wrt modifying /proc/slabinfo > > > The note here means what changes will occur after > > we modify the version number of proc/slabinfo to 2.2. > > As for the replacement of tools/mm/slabinfo (that inspired > > by Christoph=E2=80=99s suggestions), it will be implemented in the next= version > > or even the later version. > > So what is your motivation for all this in the first place? You have some > monitoring tool that relies on /proc/slabinfo and want to distinguish > reclaimable caches? So you can change it to parse the /sys directories. I= s > it more work? Yes, but you only have to do that once per boot, because > unlike the object/memory stats in /proc/slabinfo, the reclaimable flag wi= ll > not change for a cache. > The situation as you mentioned is very suitable for my current needs. My original intention is just to get an intuitive slab screen through a simple =E2=80=98cat proc/slabinfo=E2=80=99 command. As for the description = " comes from the collected results in the file /sys/kernel/slab/$cache/reclaim_account" may not be appropriate. Here I want to express that the column has the same effect as traversing "/sys/kernel/slab/$ cache/reclaim_account". > Would tools/mm/slabinfo almost work for you, but you're missing something= ? > Then send patches for that in the first place. Changing /proc/slabinfo (a= nd > breaking other consumers) for a quick and easy fix with a different solut= ion > planned for the future is simply not feasible. > Using the slabinfo tool to parse /sys/kernel/slab/$cache/reclaim_account is what I think about optimizing future tools during the discussion. It will not affect the current patch 1/2, and patch 2/2 is mainly to supplement the output examples of proc/slabinfo. If the community is willing to accept it, I will only modify patch 1/2 to implement it. Thanks very much! > HTH, > Vlastimil > > > Thanks! >