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 2074FC54F30 for ; Fri, 30 May 2025 03:53:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89BE06B0082; Thu, 29 May 2025 23:53:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 84C816B0083; Thu, 29 May 2025 23:53:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 789466B0085; Thu, 29 May 2025 23:53:17 -0400 (EDT) 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 5CD6B6B0082 for ; Thu, 29 May 2025 23:53:17 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0657A1D509B for ; Fri, 30 May 2025 03:53:17 +0000 (UTC) X-FDA: 83498204034.20.B1DCF37 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf22.hostedemail.com (Postfix) with ESMTP id 888B6C0003 for ; Fri, 30 May 2025 03:53:15 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=lrjw8+vj; spf=pass (imf22.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748577195; 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=RCZ0eiiQJc85VU+FP6ZZM0jsc0h+yMyDseVLESqwUiY=; b=6o7D5io5P2rOAzES+NcsPuSdZigwPyiTAIb1CCL2NsP903oRUCRTHvOOl3fRewHgmsFwNT PJyHXwqGT4JWlVou/dVkaJhBk1v+t5eodp9qLuq7unX6rJhFe3Cl/8CZiqkmJMJd9fBp94 9Tr2FZBsoiwpl+Y/rQJ6q7htsjMgOcs= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=lrjw8+vj; spf=pass (imf22.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748577195; a=rsa-sha256; cv=none; b=op/GIaMtLs3sies43rE/wHIcWURlvVnVkJmZLh8kIH/EclO9F+yB8CDSt6f+UfuUjg7VgX 89advEW+D7+4as41zjllZIvWZ1cJoAtZxxhCJSrjovGgGyiCTsysspBRjI/7JBUL9NO6hL Y6pAG/1N7IzImK3FTUM7f0G2sVQPSok= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id BE962A40A96; Fri, 30 May 2025 03:53:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E929EC4CEE9; Fri, 30 May 2025 03:53:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1748577194; bh=dQQUntt1ss5Ok8Y5E6ZNrvwcuMGQPmjWrkgxYZOEJts=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lrjw8+vjHne+Cm4nbQaTnY/Yw0sQCNrd1cLA4RbmsUYgUlPBQTKvVDv0t1vHDCFDX pqQAHc+ACogHUOQVS+w2L4TePGUdleQf2ZDMYi3Nsup9QWV94FZgEGc/6znc48+fZW FRIQlR2e25SfNqJBkSJhHz/VZImmH9BV8GyeAczc= Date: Thu, 29 May 2025 20:53:13 -0700 From: Andrew Morton To: Baolin Wang Cc: david@redhat.com, shakeel.butt@linux.dev, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, donettom@linux.ibm.com, aboorvad@linux.ibm.com, sj@kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: fix the inaccurate memory statistics issue for users Message-Id: <20250529205313.a1285b431bbec2c54d80266d@linux-foundation.org> In-Reply-To: <4f0fd51eb4f48c1a34226456b7a8b4ebff11bf72.1748051851.git.baolin.wang@linux.alibaba.com> References: <4f0fd51eb4f48c1a34226456b7a8b4ebff11bf72.1748051851.git.baolin.wang@linux.alibaba.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 888B6C0003 X-Stat-Signature: 18ph1n48y437qqbcctyoigm8b4qob69y X-Rspam-User: X-HE-Tag: 1748577195-647828 X-HE-Meta: U2FsdGVkX18iRtybQfNvmKewKFrc3IYtP0NVn+lz369vjMqbzrXNPgs2OMidd8xnl5OW8+V2SSpubOVZ21AssiU7NIQuA+lhhjhdxdKXY1JC9IlP7pao9wk90AxN1Q69DitqI2NKHT/pUSSeoLft48hG8Xs0u6qPSZ5xcU9jXRzZzvfRJ4hEsg0h77xabVevRUv2ziNOFqGp4LLNEV14U9dRq8norLGUNKhoQFuHucB3HOGv+iiYdW+diV4q5/NvHf0Gd6wR67IgWUx7RvOYlYq37D/StzZn5b6VC023mCOHN3BXC5a0NfxBqq3HN4eJK5U/6q5OxbFFiK8HQiwFBGUSSfVtI6eu0mKKg4OzcwG7dOyS4rPPAb8LvhziMGoe6tHjEezt4SsLZQ97CC2Xx3bO3Ia4/idaeEOx4HqD6vW2PHGWhExGUKnQdUyW4DCQxrfUcN2jaG8f0u/MmVIiHPiApQdilT1g97HnHIZ6uEfpzUXXDbT56Q7KnSx/G55mcK5NwtHGlQTZxSK4RY6iaHGaYFK16OznfyDbhX5UUY34XN/2z4Kb9oKopoVTV8VJlAfFLunvDk3CFLZt79I6ib7EFqcCDOggjZhMq0NCZjLe5h0ZMO972UL/3Ft93cVji/xYuULDZTjOaZYC2002uzzQqZdWOAgHzwn+EWWvLXTxDZkKnyZRVPNmUduh5NkAnn3fgPfGrtqWpf6uNVq2Oy0fBN0xbw8X8tj5u9hWEgBHONqSnlV7NeEbXDCajBE1aZEw7ysiNQNrR6/IRWQZbUu1PAH3nYarjHnRQTSYoPuI/eJQMOc97XQspBH6q9K7cF6TFqPwI2brgPr08/O0jj9UqzvMaItAJeKLRxsEmmJTiKFwWcLTdxokWYML9M/EUmfcLx8e1qA5ZxVWkDAcapagSJiX9lse9i6e2X4cXfE= 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 Sat, 24 May 2025 09:59:53 +0800 Baolin Wang wrote: > On some large machines with a high number of CPUs running a 64K pagesize > kernel, we found that the 'RES' field is always 0 displayed by the top > command for some processes, which will cause a lot of confusion for users. > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 875525 root 20 0 12480 0 0 R 0.3 0.0 0:00.08 top > 1 root 20 0 172800 0 0 S 0.0 0.0 0:04.52 systemd > > The main reason is that the batch size of the percpu counter is quite large > on these machines, caching a significant percpu value, since converting mm's > rss stats into percpu_counter by commit f1a7941243c1 ("mm: convert mm's rss > stats into percpu_counter"). Intuitively, the batch number should be optimized, > but on some paths, performance may take precedence over statistical accuracy. > Therefore, introducing a new interface to add the percpu statistical count > and display it to users, which can remove the confusion. In addition, this > change is not expected to be on a performance-critical path, so the modification > should be acceptable. > > Fixes: f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter") Three years ago. > Tested-by Donet Tom > Reviewed-by: Aboorva Devarajan > Tested-by: Aboorva Devarajan > Acked-by: Shakeel Butt > Acked-by: SeongJae Park > Signed-off-by: Baolin Wang Thanks, I added cc:stable to this.