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 4AAF1C54ED0 for ; Sat, 24 May 2025 01:25:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DA9A56B0085; Fri, 23 May 2025 21:25:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D811B6B0088; Fri, 23 May 2025 21:25:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC09C6B0089; Fri, 23 May 2025 21:25:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id ADC436B0085 for ; Fri, 23 May 2025 21:25:40 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 685D71D4AC9 for ; Sat, 24 May 2025 01:25:40 +0000 (UTC) X-FDA: 83476059240.20.3F197A5 Received: from out30-110.freemail.mail.aliyun.com (out30-110.freemail.mail.aliyun.com [115.124.30.110]) by imf07.hostedemail.com (Postfix) with ESMTP id 49DC740007 for ; Sat, 24 May 2025 01:25:37 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=nZ43NjLb; spf=pass (imf07.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 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=1748049938; 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=/TDP53dyJqq5lJvlbulEFVZWA288bXU/fQlMslx8xrA=; b=Bc5ulVrPnzrfahX2rJBExGeVIIUu4P9UF0MR0A4RqoGJRcngfT8Z7crSRdn/DqhnDPSNX0 tDNEaOL1CyqDt5HE9Hqy/jRHZ23Z5l0d02sm3KzHPJydrsGqTXuMtmY7joNhd5miOtNPwn pwhsWxuiXFf0XMGmjgGV+jnHGQpf934= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=nZ43NjLb; spf=pass (imf07.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.110 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=1748049938; a=rsa-sha256; cv=none; b=x9sAZwU75jch+FHC4KziRHS1pSUK8IntJ4eDsBIL9xTMGo+hqNhJb34JEY1S9f+zPxgPP7 sPFuUVJnQ4pw+vlIj5zJuSGaZM+GuoKHMjHFgPnAmPntoiA7dO70k9eQm49nG45faRg9ld WrmyhktVtI0tFbjlfYkakVdcCR4MpG8= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1748049935; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=/TDP53dyJqq5lJvlbulEFVZWA288bXU/fQlMslx8xrA=; b=nZ43NjLb4eHpHM9ckIzLB3oucv7p/0Tq2OK3D4FrjqpMKe7pAJKU5oT8yLwH8Mof5y/sNDWbCJZVV0LowqHAP4hD0pc3P77IIIFKrS4che4pkSaQvYkZV1STcflhKvISXapeweZIS/6MRsfw0TCA23clA7ZnBnI4pIRQ6/6/Axs= Received: from 30.171.233.170(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WbcACGj_1748049933 cluster:ay36) by smtp.aliyun-inc.com; Sat, 24 May 2025 09:25:34 +0800 Message-ID: <1963f1b2-5879-49a8-99db-41acbfc58ff3@linux.alibaba.com> Date: Sat, 24 May 2025 09:25:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH] mm: fix the inaccurate memory statistics issue for users To: Shakeel Butt 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 References: <3dd21f662925c108cfe706c8954e8c201a327550.1747969935.git.baolin.wang@linux.alibaba.com> <67n3snrowiyxjw6grddyer7np5rpnpg4x5f6bsyonmgcc5k5eq@s5v4ux27i4fw> From: Baolin Wang In-Reply-To: <67n3snrowiyxjw6grddyer7np5rpnpg4x5f6bsyonmgcc5k5eq@s5v4ux27i4fw> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 49DC740007 X-Stat-Signature: k7fgyq969dzzu6f5rdko4f54s75amg4k X-Rspam-User: X-HE-Tag: 1748049937-513625 X-HE-Meta: U2FsdGVkX1+9ofDERfFQJ6H3v8F32dZg9W5XeUVIy6KZAxm/jz9OHSIQ1jX4AXwtCj04HE/OwAnt7sBkdsKuqUem4Os0SslUKBxKjLt7O/o7HG+GVrlghxKX9KNoCPfXjhy8cn+kQ9b3K9XlekZL+bMURFBdHxBt3Zgv2trHN1lbekZSSeCxMqm9/Q3924KaU8JsYy4wlm4dM7DP4R9jwBQJySlxMhRyRRRZObb6vmEBq03cw226foROK8nk4IDR6gaQj6Srm4i1joixKCEDnm9RqpVofEaHZyi4F4XMU09AhwdFiUxnAbz/TCmSmlC8G8mnjDv8a0OdUCYN7Zw8kFpmoMWSqidOZBs1/hpfdYqbDIi0dL/+LiCLfO70qc6hXjAGOdAADZnAjwEX4cQeg+TGu/rgQ4/RvupNr0qQPVlmkOt0t1cdpsK3DfcfhrFGmK689QR00ikCVEEtF0Ve/M0G68NtSnI3kMLxL1v8ZYb5TJBkI7uCDdNaoMj8uPUhumi1hALLUYTN/ntx+Q9j8goM4wd9rsnXhJgLOfr8TuzRd53+zihSRl7GD+u68zeTrm9eeFcpsqtVBnYmkM4DbpRn/p7U6hzm/yLjFw88IWSS1wSeEXSG2zqUHgBPQFBTF2Un+hI6viAQQMLKdnnII5QaUlahXdOC3Y7KSin4DuYshHkDvcJWS2VFHPCAvkEP2kqxOjdYAX0ihKNIEgHcMueo73e6zD8d3/nS7BpkpuOJCl+SW/Xki1N8YNjX4GKdfNx6F2n18tFq3VMLPkYLNXl0RIUfXE50JL/ruTWKBjSFECXxEACGbU6RiO3RNhbEFk8eB3aGhb6ErRbme6PMg9mDGee+MOJNqwn69hOALPVJviMTe32zNj0CdXbPQWfLlSbpl7UgJINgUN1jTDKbt2aKuUPz8dITCEW0wyQ1qGCnbtddSdHEtksPsKNrmaKrIybQBrrhHTF5wHBIwOC b52r1OPJ jpB3PnxvHpzlbddy3eywfVJPuXnhaOfoZZC0odbuShlz4NRuO9Ow1b75PdQh9P5skBw2k2QM3j5cKoP6k69rBLyK04g6w19JwK2q7lm2xJIxef+YrDVMoL1/3vqTUIRh/9MBnCHYZNQHvy8MoEuWGV+4fziEtxiKsWEymqpa4EmP0ph5NqliEG4/ccBYLzdztu8yLnWxaOn/735tDUqcHYX7DfsO2s75D6ST3Psjjp5A41elIGeBbPT1qUJjDUFmODNkVQL5krcb6I2vqpiB7jxTkHnkq4n6vZ5dPM3X0IYX4CqPkHPOQb/zBXw== 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/5/23 22:11, Shakeel Butt wrote: > 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. OK. Good. > Acked-by: Shakeel Butt Thanks.