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 3A60FC48BC3 for ; Tue, 20 Feb 2024 09:45:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF9C66B0085; Tue, 20 Feb 2024 04:45:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B82A76B0087; Tue, 20 Feb 2024 04:45:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FD346B0088; Tue, 20 Feb 2024 04:45:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 896DE6B0085 for ; Tue, 20 Feb 2024 04:45:52 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4F5E1A0666 for ; Tue, 20 Feb 2024 09:45:52 +0000 (UTC) X-FDA: 81811700544.03.0680AF3 Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) by imf29.hostedemail.com (Postfix) with ESMTP id 64FA912000E for ; Tue, 20 Feb 2024 09:45:50 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YGkFUGtp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of fangzheng.zhang1003@gmail.com designates 209.85.167.42 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=1708422350; 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=BHyj07uLVXJcBsbcgmGTKkOhm7lqfKjgr9KR/k4BgLc=; b=honaCvFxdJDJMWeHGsImzi4qIAA5XXc9FM+0cprtRwA46jQo4IMw5lvh4ql6qw7GxgUxfT sCraH3PTBCCnbiLCAYzoR3MyJoMIeAY6ejJcIZ1DxplWvtj/ztRf+MuuGEDF9HaI0ujghM BPeobhCXU30Dy7RE0G3LfuYavpSm6NM= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=YGkFUGtp; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of fangzheng.zhang1003@gmail.com designates 209.85.167.42 as permitted sender) smtp.mailfrom=fangzheng.zhang1003@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708422350; a=rsa-sha256; cv=none; b=bjgANH6tpleUSYTwPROSc80eWiHeKk8nfPcjE+Yr09HGSRqgZwhu7vehF3B2lC6A0QlFNS X/5J3xFL75mZ2kE3096ZQzwJD88jcQ/GAqoG9LrAJgCZUykiiHBHPj96CBDSJe4vRkqniS l5MsFou5NjZoZqTJynOmWrtmECsnQNY= Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-512a85806fcso2838740e87.2 for ; Tue, 20 Feb 2024 01:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708422349; x=1709027149; 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=BHyj07uLVXJcBsbcgmGTKkOhm7lqfKjgr9KR/k4BgLc=; b=YGkFUGtp0cgdxk2hmgI6o8wsTp880MRDxpbLYX0HWmzzA8BRFflSdNCkV3VGd4gwCm EFxZUgVrVsfxuLf1Ng+XmZ9/9yqHCt4GDbQP3ry2j0kYY1v946Y1yFHqkCcj/QNchUbR 8JcYnpXhYOjurGn8LqIfubpsUDrbCo/7XByM7TaJggXjYsxlzkNpmrakS70j6O6RD+An 82Upab++of8zSfCmc3gOhYZGI0kK1L3MKmi0QAg9W19xwdazGSS0I7dRHFCF95E4pybn aUYtN7cPvmXvy0qfcwh27BMf1FQqW1a2ifNQdbgBCGnv9dixvmIByMkdHiP8eIbff4O+ BJHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708422349; x=1709027149; 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=BHyj07uLVXJcBsbcgmGTKkOhm7lqfKjgr9KR/k4BgLc=; b=Zdnl27+hbZu5XzNyylAq9emc8yH7ZZdj4sSxOcELOba6K2BGtng6YXftGrj5tS0hM1 ZIhRIx8M3jiy1L2XIt216gAEr937UC+8xCx696j1W2cToWI41jOaTcV5Ot2soV0HOCac Lx2DFooj/y+aztgLwLLjLEzYCgrimUFyFVzT61kAdRaLzlXsBwc0wKKNuWoTAAoFU171 B8z+DMP6itrzJpQU5Ajo/kZcAQbca8ftKUbl4tsMC748sXz/kCSbWHlyBpjlMIG4JBql Xw+WWLeoJlrEIDa1ZDJfLZFIi/fS/zchI8yIHnN0Bdeg+cGu2IHQqnfTSWc2rnejxbsT GRFA== X-Forwarded-Encrypted: i=1; AJvYcCUF3ENacCcqak8Hc4qMkgDPImXjU6hlX+/u4YU6+bkPubJswOsBvsAHzvCJXffpNAPhLiC9Igdr+tg+CwX0U/ho93E= X-Gm-Message-State: AOJu0YyHXGTDtJNIwZl0d1I2vDpMcC8o4lQY5sRtH0CjSkuHYG5PQWAZ 6hfcnYCRvsIVuJE4xQxCDIPP2W/gt5TQ+fVGQ/SIpqeX66FjgERy8zi6wUP24YtKzWnyPqffuu3 vgtHqKB5XLc57sKDH7hTGijasUA== X-Google-Smtp-Source: AGHT+IHl4ezSlLgTZQs5G2nw2vQKKtig2O/6ZkTZZp3VSK8CfuOTB+Xb9h8iRXkVtYqOSdN+f+5Lmpd0MaiReG88BDE= X-Received: by 2002:a05:6512:3f1e:b0:512:c8e0:5a27 with SMTP id y30-20020a0565123f1e00b00512c8e05a27mr841605lfa.39.1708422348495; Tue, 20 Feb 2024 01:45:48 -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> <60edefec-0a78-4c23-bfb6-17ebf326c61a@suse.cz> In-Reply-To: <60edefec-0a78-4c23-bfb6-17ebf326c61a@suse.cz> From: zhang fangzheng Date: Tue, 20 Feb 2024 17:45:36 +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-Rspamd-Queue-Id: 64FA912000E X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 4pns4iccbq73m8j1jh8m69mu6f3bwoqm X-HE-Tag: 1708422350-83187 X-HE-Meta: U2FsdGVkX1/rLEvw3TgB5Phsq5G2Y3n8MRJjmN+rZwcIip4CuwbTYD+nB7mSb5ZjN3EiVLC6qS+Q3zBM/GjKPtmBp5IqkXvoGqSUrkaXHCQIHhrD0C1rlaKJFweuR2B9k7Lohtg3EFcnx+wM2pMF4hLAQ3ZOV38GpZ5KmWWdicciyNRt3UY4xhdn70h92NWDMah/jJ3LTPemEFjDBPosDRqcgqix+CJR1j23fN2TVOhSwdZQooRjnafl62DLRLSKtd4FXqft7AUSAank1dvDW/Xm0axgxRll+eX1AWRPkP4OBuPYuz2JR/1RQOtREXt3ZINC8JrXSgtFweOFepKvt5bgO7fxz5D5qAaj2mLXSHV42EBT1iH3K1bq+p5uC4y54186DhWX/MaR4X97FhApU2hcMJ9qHPry4GgzfUuOjMy1y0KNQ37llTPkCMsW8tNY1+//erEyQf3/1uLrPUebcf4dfKJILqYeTtpNVk9J2w+5WzyzfxB+o94Ia3ZsU1Tyg9PeorlO7Fq2N7VUflSeK6883LUJTF+LA2ewXiZztGT/NdqVYgv3p923cwRvDCXFIW8qocyDVKuUzrck2J1pS6DLtSV7y+Zb8l+qM+YZiwbC/n8Zj+vL9p7bPKO8tntLImGgt+djSsefoeQZ6+zaNVA3/YkNvmd/5WuCOLdpn3pPcAWDHv55OvkRYrKs2sQFZHMGIhsO0wuyaOU44GRv49ZsDZCe7g6iVmtG/knZPlb7ij/d9aF2fJYYfuijuqoRO7jOtCk1gTSm6znC8LTcACI4J3kxcDWdwTwHuuA+ivkWlMTxa9Rbtd4SEFhXA5x5JliLy9pQJix7fk/jvc2lRv4qa/9A5YFXlrIR4Fm0JNiR8MBhLGKLY1PHj/ryx80OVy0pFvp6EiBpdlMmrKa3izKkOcE0GeF1Hhid1l0nZffktxnCs6ec5fQxozOQA35sdaNUAOSC/59AP6iXREo xmv+a5xI EdycTEyLGWzzDlxeqyRZsGJzfVg4xz5TFVmIIerUMbDuLFH9FoIpFmqsfZgWlKClcJ5uHnNaFoR4YTqbOrDoXaXpilF+9VwUv7xHprehckBf7gMidU0tHj1dLYO7Ij+2ka4daFh6VZAFTprb8zkjHvOzsopimyNT9DjrqZd6/zoWp7rouinQhY6ewBuuYcGgxHxfun5Qwo7oxco4Tqx6P+uMtDBlvwrUxck2AyB9vLLT/dqsxo/i6jx0Bo8wqYM3ZIYXmQeAouyRLYCpzxm/y6ozOQtL86+KBduPnrwXBNbGtAGFVWvMbpQsasknkyiOzywHLIYshXccaTL9vY0N4evl94R/POJbjZhTUhA/k2qpi84nYmHtV8pPilDf+FQoJgK3uCnp0FGMDlzcXQ+E1arNFa1uaNpVmwqlM6Ox9HUiodwu+pWO+ZQVmmR1P3CtTajE8EaCD7QCqnNfGblOCATFJ01GD5SdTmR2hIyQKPTfSlVaiofMPKOT+wtk0dTGhCNbDIayKESrGmDGi4SCO7Hlw8PhMFvy94kFdgONb6BuDurw= 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 Tue, Feb 20, 2024 at 5:21=E2=80=AFPM Vlastimil Babka wr= ote: > > On 2/20/24 09:49, zhang fangzheng wrote: > > On Mon, Feb 19, 2024 at 4:09=E2=80=AFPM Vlastimil Babka wrote: > >> > >> 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 /pro= c/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 cur= rently > >> >> 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 t= o > >> > 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 k= now > >> 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 an= d > >> refuse to work > >> - confused by the new column they start throwing error, or report wron= g > >> 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 sla= binfo debugging tools > > (such as tools/mm/slabinfo), > > Hi, > > we are not concerned about slabinfo debugging tools that are part of kern= el > source tree, but about those outside, including those created privately a= nd > we don't even know they exist. > For your concerns, I think the supplementary introduction that new output results of slabinfo v2.2 in patch 2/2 will be necessary. This can help them optimize their tools more quickly to adapt to proc/slabinfo. Is this more friendly? > > 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 outp= ut > > 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=E2=80=99s suggestions), it will be implemented in the n= ext version > >> > or even the later version. > >> > >> So what is your motivation for all this in the first place? You have s= ome > >> 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 =E2=80=98cat proc/slabinfo=E2=80=99 command. As for the descript= ion " > > 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 someth= ing? > >> 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 so= lution > >> planned for the future is simply not feasible. > >> > > Using the slabinfo tool to parse /sys/kernel/slab/$cache/reclaim_accoun= t > > 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! > >> >