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 2B09DC54ED1 for ; Fri, 23 May 2025 14:11:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4725F6B00CD; Fri, 23 May 2025 10:11:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 422456B00CE; Fri, 23 May 2025 10:11:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 337E66B00CF; Fri, 23 May 2025 10:11:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 133276B00CD for ; Fri, 23 May 2025 10:11:48 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 4360ABC153 for ; Fri, 23 May 2025 14:11:47 +0000 (UTC) X-FDA: 83474361054.23.9AA76CC Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) by imf08.hostedemail.com (Postfix) with ESMTP id 4E971160004 for ; Fri, 23 May 2025 14:11:45 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=gEuVSLBC; spf=pass (imf08.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748009505; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Iyyet1GA+O6fAfZqBulBiVthKT8i/nPLXStWszD73KU=; b=sEDRS/7LwhIsM6xYHuZu2kD5RBQV295tGThxD/ikQpWjFDZMDhJ0aW8nDtM7n5GDQiGk9J sTuSGYZBCR7pK2tBvEZ1mhB2PI0fhAmxypXDTGcAyD+Db+cT3e2iMSQi3yjiznhnJLWiye 76zHv1lk1hTS1P4TsSY39ts6y/r8oTU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=gEuVSLBC; spf=pass (imf08.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748009505; a=rsa-sha256; cv=none; b=3tMRQmJ/QefLTSYuG87G23TsR2XAjNuW304XPTRIQf9X1vA/AhkuhKgqOU9x9J7jxr2jFQ CYGmdUr7+Sjm4+fT8EMszkjtDx1MEvJ46xqxteADciJIRm1Xlnx8Rq7/h8/bu/n3dRwMrB i9FqxU8Phv3zJvMY7W+xHUgfdsi9c90= Date: Fri, 23 May 2025 07:11:37 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1748009502; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Iyyet1GA+O6fAfZqBulBiVthKT8i/nPLXStWszD73KU=; b=gEuVSLBCr5UjNnMYC8OeQ3Sthe8ILLXGKsTiqBZPNnh4RyR8kxUPoWpHiZYLAfwebC2QyI BItrPCu4pTBo0vIFVnSanAmYCAnDvTGGe4eVyuO8V8zdnITDmnb+eS3sIJBPODSnrk/0gM jLMF+g84BE546fueju13H+8zJ2fs3GY= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Baolin Wang Cc: akpm@linux-foundation.org, david@redhat.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] mm: fix the inaccurate memory statistics issue for users Message-ID: <67n3snrowiyxjw6grddyer7np5rpnpg4x5f6bsyonmgcc5k5eq@s5v4ux27i4fw> References: <3dd21f662925c108cfe706c8954e8c201a327550.1747969935.git.baolin.wang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3dd21f662925c108cfe706c8954e8c201a327550.1747969935.git.baolin.wang@linux.alibaba.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 4E971160004 X-Stat-Signature: cscpigb5pdqcg7cj45jpr9tc9nqt5k4t X-Rspam-User: X-HE-Tag: 1748009505-671901 X-HE-Meta: U2FsdGVkX1+PdgD2D3OI7JnpPS+NYpLvg6cNGkLJ8oAMiEGLTfvVY/zLBcPQJ0pLUP20ovvOXS+HZ2ynZSqbp9RJfeum3/OBa/Q+kSg0qkCK64Y163qLpuFL53PS8D60+MJHUMsaC4IXmp3iQQ8W0Uq9SsNWGV3AfS/8/Tpn8d9AtbTyIr4f83rjn17sLHXDG7Ua7qoIP6+WohC092aWdguF0YY61+uYOnF2ot4OykzszZr3rUc5d5LtgL4ktCNBBLOZ4h4ApT0xd9uqkubNRS0KqqGI0S+Dh1qbTsVNyDt0QdfPL82i9gFAwfRLC5PTf1QL9e/27c2LvYyANw4KZZXL4x6QDSSl3osfX6OFKSeV1GnPKKZtPZu7PoJJPY948yP4OAQbABxfx62B7Ydcrj3BxHVOTahagk6kaD7iWlgMVfcPv2bfAMIKvwpkaOgAaBEM8v7TNopdf93TCghD1XKD8b1k6iw9uPhfPk6pW/WAnHgnbCfK5XLwN8QlOdZI0285YyguTDuOXWTKL2j4bF4RLqEgKyErV1Lp0rINsAKXFw/PyORYBuB8UuEFmxlcYOaGyNOWkBcBUbSBgCrsGjT3Onlb0hXXcymyNKSs4auHGfbytJnSmH7A5mThpCvRT8B++2k94n4y48ww4et2CiK+I4hbqYbv63dq2JAod6/fXfU/HzllBA8MMeS2xq/sTfih8smSRWoMdnOXS+ODrAuZtcdndp8m7JhxomIzhmfEQQuR/qhyNORxDqVKc+H12ZWoMEY57GH++zJMoDD46DXBaA6pCWQ82f7gPA6hbzVeWsOdzlKJZzBLdX+tCg6E2Ca0HwtvSeoZHhIve2np9YJs/RrcNzg62yCIxoumu8voejyJRNBmlOVr9JhXH1wQ39p2KC0onVLxyRpcIpQYeXCPAEa4dpbpoEUUDpJK+yCrnehRF7RwPf3uEv7VF7reLffgbXKNXFErwB2FjWV Hj3MihsC +IquDYXwbi/Yu+7ekOqfCMWRkXxMykrzYPCF6dkrKeH5tsTDdas0bNg5+5CrV9hp9dOeIc3YV3R1c/VjsifL3EOUNZcnDUSt+5rvmw8jcizUY7rcaf5PsEuG7dLhmqGH6CZeE1fTtsX8cgtweO7XHPQLidyvQGLy5H6P3i4yEprU3CjVjnRjbDC+9r41XwwzenemejfEZ1EzMyzIJ54LHz3xC0WpNI2YHFjnyaWpjTQ49YXY= 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: CC Mathieu On Fri, May 23, 2025 at 11:16:13AM +0800, Baolin Wang wrote: > On some large machines with a high number of CPUs running a 64K 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. > > Signed-off-by: Baolin Wang Hi Baolin, this seems reasonale. For long term Mathieu is planning to fix this with newer hierarchical percpu counter until then this looks good. Acked-by: Shakeel Butt