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 97AD3C48BC3 for ; Tue, 20 Feb 2024 09:21:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1D2826B008A; Tue, 20 Feb 2024 04:21:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 165CA6B008C; Tue, 20 Feb 2024 04:21:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF1F56B0092; Tue, 20 Feb 2024 04:21:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DB2306B008A for ; Tue, 20 Feb 2024 04:21:29 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 9CC481605C3 for ; Tue, 20 Feb 2024 09:21:29 +0000 (UTC) X-FDA: 81811639098.18.6A5E852 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf25.hostedemail.com (Postfix) with ESMTP id 3BF68A0006 for ; Tue, 20 Feb 2024 09:21:26 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="E/GiE8EK"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=YiMkR6mr; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="E/GiE8EK"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=YiMkR6mr; dmarc=none; spf=pass (imf25.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708420887; 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=6Sjz5RfeGjBV7xfeElN3pstsDd1FoRAefaT6PJlcvpA=; b=59MEf6TsKTbBBdGCuG96B4WxKq2fg1L6jdb/H7Pa5ZwyDzdq99lJetaqCl1uHlUxq9NJRz iWVUhLXGMunjpTpxrCU/M2B/V1t7Sd1upwGOiBnhD+wLpvbl+aTrNIBv9joykNiBSsMdCE 4wIlgw4WA1tomJzrxAUVYgP0lD149mk= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="E/GiE8EK"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=YiMkR6mr; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b="E/GiE8EK"; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=YiMkR6mr; dmarc=none; spf=pass (imf25.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708420887; a=rsa-sha256; cv=none; b=cYuIqzM8IHZ3xajVcSSg3AQDFzitlm75mHBADhxON1Rw1abUTcSImQZBluA8SZWiHf3tau 5ZF0xFcbKnXYABN8bFwYkKBWius+yN0aBAE5Rz5n+pAjJf5Dr3b59H24gBn2N8jTGsx+NS ntitCCQXq+hEL6dkUxUn4VWYrBR4x9M= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 57B4C21F61; Tue, 20 Feb 2024 09:21:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1708420885; h=from:from:reply-to: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; bh=6Sjz5RfeGjBV7xfeElN3pstsDd1FoRAefaT6PJlcvpA=; b=E/GiE8EKD9pbhN+BYbILJD+tM3xDhtj7srYKtbS8h+RhJTZp7Urc5YlkXdvlOJBkDKyJ80 s48Ta8BSjDAuMF0HRfQtil0ljGjZ1ZUuyFIjuWPbhIxJ9gHZKo85mnDo9hvYYhRAwy/ET1 MOB00Xi9FHkqYr4MiQIDvwcpTQ2nOL8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1708420885; h=from:from:reply-to: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; bh=6Sjz5RfeGjBV7xfeElN3pstsDd1FoRAefaT6PJlcvpA=; b=YiMkR6mrlwgQKkyAB1F65P0748ggXq6VbxQOmOBGSIU4xK0X9cMiOEaPRt198So/O27P5X 7H9u4aJEoxtSrGBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1708420885; h=from:from:reply-to: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; bh=6Sjz5RfeGjBV7xfeElN3pstsDd1FoRAefaT6PJlcvpA=; b=E/GiE8EKD9pbhN+BYbILJD+tM3xDhtj7srYKtbS8h+RhJTZp7Urc5YlkXdvlOJBkDKyJ80 s48Ta8BSjDAuMF0HRfQtil0ljGjZ1ZUuyFIjuWPbhIxJ9gHZKo85mnDo9hvYYhRAwy/ET1 MOB00Xi9FHkqYr4MiQIDvwcpTQ2nOL8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1708420885; h=from:from:reply-to: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; bh=6Sjz5RfeGjBV7xfeElN3pstsDd1FoRAefaT6PJlcvpA=; b=YiMkR6mrlwgQKkyAB1F65P0748ggXq6VbxQOmOBGSIU4xK0X9cMiOEaPRt198So/O27P5X 7H9u4aJEoxtSrGBQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 34895134E4; Tue, 20 Feb 2024 09:21:25 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id WSSDDBVv1GXVZQAAD6G6ig (envelope-from ); Tue, 20 Feb 2024 09:21:25 +0000 Message-ID: <60edefec-0a78-4c23-bfb6-17ebf326c61a@suse.cz> Date: Tue, 20 Feb 2024 10:21:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2 2/2] Documentation: filesystems: introduce proc/slabinfo to users Content-Language: en-US To: zhang fangzheng 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 References: <20240219031911.10372-1-fangzheng.zhang@unisoc.com> <20240219031911.10372-3-fangzheng.zhang@unisoc.com> <4591b2b3-398f-402e-b21d-55b244f05a2e@suse.cz> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: egkr3dt519bo1njqxc67ye4n4wpxyocp X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3BF68A0006 X-HE-Tag: 1708420886-175970 X-HE-Meta: U2FsdGVkX19Pf1KGA8FUQrif/TKa+BAgfnOTlZ9MvkdG18Jmd8IbPoTZvp28QvEAy/CUzipMl+0+n+5lhqJFhs6coH82Eic4wiBy6ySJUeWPAuRHi3FasSuBaMOEo3NHGnC4feCW2a+NBWrmWJGfNA3YSBZPw8UTRm2vbCcghzK3XPYykdDjLZme9JYTCx2hQfOfAKC5b3wBla7jmNQkKsxx9gnR8K0wjfZOoTKfSFg9Kpa0kNak6m1r0fND595gdNRhq+DEVNyv/L9W4aKYfPInswks0EhU7jNxiuPIEQF03tD09oNvaJZ0phV3y1vDwHuZlglxA09u3F2LwHmG9PE/WAgQISpGhdiZIMHXuEL+lX4XhUgkGG05K7Im1RoxFJ7cLOy8q4vwz56rL85DM3uKGkcrQ2NjbkUw7BYiB43ky/XMmPrKKGcqxvqeX72TqrR59J/+Pfmfu2bqLgR9Jj8r1e621hCoUqiLdTpGfopHU5Rx18WL4ZIMJko0BnMzBYbVmqfiFY4SmAyKSKr5xBwAsrLgKprU3+p02dkpLFOVGoFkNJ+k1QRL5s4qf1G2CHtZVJAcma3aQHiWhyGkYHNXWw2B7A/ofiUF7t/g1XkhkTAmUc5ZpmiuAzyReOW7XN6VFC+FT5vhVPiB6QtL/qL+L67M0aJYGCy4Pm7jfQ0xmK/vPMgy8FHGwLuE68BAgRvP7TzYHAwgOZzgi15agoq4SMgAU6mNqF1C7jmfVCWBsIRUh1QmV584XnMrxeu+hk8N8ODxJ+hFvPhP3U+EfI1RoASkvqaf7X2Trv9QATX5NR57oUGdBuW83KY0o9hU/J9eH9MTeAV7l6hRvWYD0U1El3Qb5CRVRUNXWw2XSl8f8vwQNn5mrsS4a6t/Tdigcpm6BEAM632HSGKdAW8Zf+0PFjpGTuUKRHS+cTcbQSNgeTZ5uRGz+eJTv3CtoiHBXbEoe8OWOKfeboL+riR NbN862J5 2y9HdjCExqg59N9TIPVN1nOQY5dNBn5grFDrAVLS/HVYEzp8I6ESjraL0A1gTNOQPsvSUkFBYO4jr3kXK4pUImjqG3ccMAVF8Qb3TagP605k9pKw3tpGIvCma6xA5gUfCMxaWa44pNbHbDYMi6arUI4gfaYM/3MoK6o8OdAmA6yjI01KH2hKttAWQRmwX12hTJogis7c8/t7u8ixDcm7F9AsOvbEQPazr0cm6WyR5a4pspxH4Lbzv59uuAAX4AXhIIHHVTJR57MqVZphxEptdVA9deW8SaCQpJO+poPORYibquGk8FhMs56UFvgOEYD4mOipn1VFtt9TDKB9Elz21ffOsgDwJhEBqBuXQaCvHKm6UFpvBNr2PTjFJIga767QinDVzAHFc02rlInnoKFr5uFGUwceLIESV5i3vYQDXMTdHYwPnyNtmHBhYVYQnSWP+5T8tavpMZX1Jmus= 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 2/20/24 09:49, zhang fangzheng wrote: > On Mon, Feb 19, 2024 at 4:09 PM Vlastimil Babka wrote: >> >> On 2/19/24 07:23, zhang fangzheng wrote: >> > On Mon, Feb 19, 2024 at 12:24 PM 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/slabinfo >> >> > +as deprecated and recommend the use of either sysfs directly or >> >> > +use of the "slabinfo" tool that we have been providing in linux/tools/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 currently >> >> 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 sure >> 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 “/proc/slabinfo” is not used in related slabinfo debugging tools > (such as tools/mm/slabinfo), Hi, we are not concerned about slabinfo debugging tools that are part of kernel source tree, but about those outside, including those created privately and we don't even know they exist. > 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, It's not "only", the output of /proc/slabinfo is what those tools consume, so that's what concerns us the most. > and does not modify the struct slabinfo or struct kmem_cache. > So there is no need to adapt other modifications. These on the other hand are internal details of the kernel which we can modify as much we want >> >> 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’s 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. Is >> 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 will >> 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 ‘cat proc/slabinfo’ command. As for the description " That would be nice, but again we must be careful about existing consumers of /proc/slabinfo so we can't always have nice things. > 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 (and >> breaking other consumers) for a quick and easy fix with a different solution >> 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! >>