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 73762C5AD49 for ; Tue, 3 Jun 2025 08:32:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F23DA6B03DB; Tue, 3 Jun 2025 04:32:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EFB956B03DC; Tue, 3 Jun 2025 04:32:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E384D6B03DD; Tue, 3 Jun 2025 04:32:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C41F16B03DB for ; Tue, 3 Jun 2025 04:32:44 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3CE9D809FA for ; Tue, 3 Jun 2025 08:32:44 +0000 (UTC) X-FDA: 83513423448.16.28DB3B0 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 61372C0003 for ; Tue, 3 Jun 2025 08:32:40 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=tnEmvyvl; spf=pass (imf28.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748939562; 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=bIlFp1YkISi/JWhTh6BNTs1elacf5rCr0u2jnk6x4Dk=; b=RfwZ8cq1Mn1cxsr7uo5PnjG1H468PGq09dmSSiqdIP+fUbt9LD9xPrueF4VSOr3gw/AIjE +GbUtw7kfMpbfwPMjueWbUF9gHZw9KyxhffSQJotXUh8XQeJrHZ16mB4lxXkJAMo8ru6L0 Bho34GV0E2nf2WgzETWpL3bqRgq+OpY= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=tnEmvyvl; spf=pass (imf28.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.124 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748939562; a=rsa-sha256; cv=none; b=RQsClO63ZVzhUgbzqrqkgPG1vf/3My10sBCpuNOTzdlpc1rD/AECEnPNJVKgjdDYFhZRdJ JhozMF6xu6c8I6X3sfIDtwk+8jLeWiU1WRf7QlQgAWyOldGaaVmddvB/Cwl24Yi36CZzAi eAqNKbHixXwHkxJMUr/nUYs1xg398Fk= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1748939558; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=bIlFp1YkISi/JWhTh6BNTs1elacf5rCr0u2jnk6x4Dk=; b=tnEmvyvlDJohgpJ7M3uDyyv6i0fDyo12XruVl53GTUV2gnZg7mL6sPN3rozKJnvvKrYKdOvU8M5AgR2VgoHRp/pWzZ5l29begTjpJFPa9M79nEvVcPbeZUPFza8K0tEJLG9FGxeTgy5UKMWjXqZOahzYhfqQVvAmier9qzyRtME= Received: from 30.74.144.120(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WcnIfXx_1748939555 cluster:ay36) by smtp.aliyun-inc.com; Tue, 03 Jun 2025 16:32:36 +0800 Message-ID: Date: Tue, 3 Jun 2025 16:32:35 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: fix the inaccurate memory statistics issue for users To: Michal Hocko Cc: Andrew Morton , david@redhat.com, shakeel.butt@linux.dev, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.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 References: <4f0fd51eb4f48c1a34226456b7a8b4ebff11bf72.1748051851.git.baolin.wang@linux.alibaba.com> <20250529205313.a1285b431bbec2c54d80266d@linux-foundation.org> <72f0dc8c-def3-447c-b54e-c390705f8c26@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: cgy4gu59dn6mi3bqosuybfra9jc3senz X-Rspamd-Queue-Id: 61372C0003 X-Rspam-User: X-Rspamd-Server: rspam02 X-HE-Tag: 1748939560-24590 X-HE-Meta: U2FsdGVkX19r7ajJ+NxDOjHkq2g+techewMZxs/YL+eWLrnpReUbqhxQNfxYuiQSw39rx4CPmvyk5nmv8F99WwKR3LxX3ZbcIfnY2zz+YsRsy/dWHg+/i0bMaoFjo4jH0S1tIZu/rNN3BRgPnllWs/xRgJzyzIO+JnrTZ5omBuXWbgdfzIDuir+JpPrCAZcKzM3Vv/BLBEwXtMeYbFNTw9i963LATYXKoyuvWklzF9DEPrXfyAvtT/yfR6ugMePgNVcMvOEeyA6DDvJ2+j+dCgChLpGXhqKQyx25qp7158JzVVFT5NNIqAdB973OJP7hDbBHpnYSn6iSDw1px+bOP7E+T6AerAWYmd2x9gd3z2/qozHjbs4fH6nY6LB0/jEPkNoUjd7Q/od36puyuM1MWOJcIjeX0y1exIcUyfy4z+iJnKvyI9bIH1HWXvYlwOHMSbHjo+IRI2d5lwFI9tTocKl/DpHczW48SF1dJyX8KOgIZinl18GeOTfv2sP4GUpcPiczHvA1keXq6eOBtt05FY/1HvA9bcXLzpCGGWoste23IK76H9DmFQ+P9gRaDd0TRxPSHmCx29elrNa4jsuveJNo7jmWpCyH/0cUwJd0Fa9SmZzRPxKnAxqIL0hk0zzvhjeVKHnrGQ0fqTIKecqE5rjvwgUXm438u7HfVXQ491yUaglijKWmXo6IopPMNlVYbPHyn93Cwbh4fS9dkDiMrg0d3kpX71gS4o/XwUZkr/st+DkOuNywb92I91zjqCdnKvWODMX9m+7/pSKXn01eUNbyMVhVHx+ER/y/1vcAVcDUJjYRL8yUp5lTl0//YidBEhSe9DRhNUqFB96WXhQ6czvjnYg3gJFKqAAHD0D9JvfDMeut3IG+OgisL0z7WnunspvC1a6a3fpiRawL5C5l3kj15yyne1Q+iXpk8LFqcs9TIAGs+l0S6VvUJxAXevL0sWaJlLC79zKPUG6DRXs 0J5LiAWo f8PbhGRssjOfrTYOXFQCMfxIRlw1sAEmklA2dZJwqmdUbeJof1e+Mfz92P+Z8jF57Z1mB8a/e1ltVO9YJMK47Our8KAJunCozUp0HCxTcfOA0bLW1Q2JEiPrTP7HL/2YqOr59BGVjPC6VWWH6Gw16JT7TZD6aTkxFCh5KZo/aeDFZo3u8uzY8YgFYQFB4W1WM/Mzn5UPO7jzInOTRuRMcdRFQp66EsrGQpI/WhcROpWhxFgY4EuJ1vJw+x1GSwmpLgJMoE3FWIPp9ZJtJ86DjFhecSR+zhxyfZ6Zgb/5BThwmdLkTnwFRI5GuCmallbNE+BP+b7wm4g6dfGIR5HM8EMP87Q2YDu0omrbaN6T/khbWWbY= 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 2025/6/3 16:15, Michal Hocko wrote: > On Tue 03-06-25 16:08:21, Baolin Wang wrote: >> >> >> On 2025/5/30 21:39, Michal Hocko wrote: >>> On Thu 29-05-25 20:53:13, Andrew Morton wrote: >>>> 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. >>> >>> I have only noticed this new posting now. I do not think this is a >>> stable material. I am also not convinced that the impact of the pcp lock >>> exposure to the userspace has been properly analyzed and documented in >>> the changelog. I am not nacking the patch (yet) but I would like to see >>> a serious analyses that this has been properly thought through. >> >> Good point. I did a quick measurement on my 32 cores Arm machine. I ran two >> workloads, one is the 'top' command: top -d 1 (updating every second). >> Another workload is kernel building (time make -j32). >> >> From the following data, I did not see any significant impact of the patch >> changes on the execution of the kernel building workload. > > I do not think this is really representative of an adverse workload. I > believe you need to have a look which potentially sensitive kernel code > paths run with the lock held how would a busy loop over affected proc > files influence those in the worst case. Maybe there are none of such > kernel code paths to really worry about. This should be a part of the > changelog though. IMO, kernel code paths usually have batch caching to avoid lock contention, so I think the impact on kernel code paths is not that obvious. Therefore, I also think it's hard to find an adverse workload. How about adding the following comments in the commit log? " I did a quick measurement on my 32 cores Arm machine. I ran two workloads, one is the 'top' command: top -d 1 (updating every second). Another workload is kernel building (time make -j32). From the following data, I did not see any significant impact of the patch changes on the execution of the kernel building workload. In addition, kernel code paths usually have batch caching to avoid pcp lock contention, so I think the impact on kernel code paths is not that obvious even the pcp lock is exposed to the userspace. w/o patch: real 4m33.887s user 118m24.153s sys 9m51.402s w/ patch: real 4m34.495s user 118m21.739s sys 9m39.232s "