[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdLX51r1mOEZKUje@casper.infradead.org>
Date: Mon, 19 Feb 2024 04:24:07 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Fangzheng Zhang <fangzheng.zhang@...soc.com>
Cc: Christoph Lameter <cl@...ux.com>, Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Hyeonggon Yoo <42.hyeyoo@...il.com>,
Greg KH <gregkh@...uxfoundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, tkjos@...gle.com,
Fangzheng Zhang <fangzheng.zhang1003@...il.com>,
Yuming Han <yuming.han@...soc.com>,
Chunyan Zhang <zhang.lyra@...il.com>
Subject: Re: [PATCH V2 2/2] Documentation: filesystems: introduce
proc/slabinfo to users
On Mon, Feb 19, 2024 at 11:19:11AM +0800, Fangzheng Zhang wrote:
> +Note, <slabreclaim> 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?
How about we simply do nothing?
Powered by blists - more mailing lists