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 64587C5AD49 for ; Tue, 3 Jun 2025 17:30:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3F2F6B029F; Tue, 3 Jun 2025 13:30:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F16B46B04D0; Tue, 3 Jun 2025 13:30:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E54D36B04D1; Tue, 3 Jun 2025 13:30:00 -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 59E1F6B029F for ; Tue, 3 Jun 2025 13:29:59 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 005BF1A11B8 for ; Tue, 3 Jun 2025 17:29:58 +0000 (UTC) X-FDA: 83514777276.19.1504195 Received: from out-188.mta0.migadu.com (out-188.mta0.migadu.com [91.218.175.188]) by imf10.hostedemail.com (Postfix) with ESMTP id 82E42C0016 for ; Tue, 3 Jun 2025 17:29:56 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=mizm8038; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748971796; 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=f/DQf1x6I31oeApBRZfoUsma0VTKN1+fkRmQ0qgmY0s=; b=JkxMJ/k1YkxSTEkT7CYTqGrSn5ioeY5jODB09hoIT2kqkgY53QvU9RqCwkzhZ2/KjAk+Bj udw8a3FRhBgxgwcpiUSz0wGqhs23A+pzM4zmB3PPVUNlTlbUC+oRNJHgGY7gZbiyHqdcYQ 7CLPJiQTflqnfhXF7KzXO9e4ltqq0sM= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=mizm8038; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf10.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.188 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748971796; a=rsa-sha256; cv=none; b=ITdU9cpD9DSQKJO+jSBcF4rTmeguoiaIxrRYuMISR1qpmG7PuGjT5I7jzMtQqXZftnoCEa UWs8fHA9soV+GbuXhkYcRMCVSjl16ExuyuJre4J85NXf/N7nKbRWJon7dJidlunPqK+/Tf o0m8SPvUm3H60vxX23XNRzMDj5dxTe8= Date: Tue, 3 Jun 2025 10:29:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1748971794; 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=f/DQf1x6I31oeApBRZfoUsma0VTKN1+fkRmQ0qgmY0s=; b=mizm8038bFZpD4Nm3NwtDzDJO6adEogcjWCclc6Ie//akw7hFwcQTx6/e9xz6sy15mosGe KHREMWuZnwh4e4vkLUNii1HY1lO5XL8Cxnt9iOKQQsvawwr1Kb0z8UtAih63G6KZNcxyaL Ebh6fDugT5WzOh+XLJgy4SxM5RLYC+Q= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Michal Hocko Cc: Baolin Wang , Andrew Morton , david@redhat.com, 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 Subject: Re: [PATCH] mm: fix the inaccurate memory statistics issue for users Message-ID: References: <4f0fd51eb4f48c1a34226456b7a8b4ebff11bf72.1748051851.git.baolin.wang@linux.alibaba.com> <20250529205313.a1285b431bbec2c54d80266d@linux-foundation.org> <72f0dc8c-def3-447c-b54e-c390705f8c26@linux.alibaba.com> <7307bb7a-7c45-43f7-b073-acd9e1389000@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 82E42C0016 X-Stat-Signature: 5wimdaqxrp6awexr5ceixzhmwrcfsd66 X-Rspam-User: X-HE-Tag: 1748971796-190038 X-HE-Meta: U2FsdGVkX1+D3r7iNYeDjDmUGju9OAxH8SY7bkWrXNDDzObH4Rt17zGXTwv63SGBCR/7zjlVY9g9CNqyYTi0OWbBuUrg0ZFglNytRfKZ0BGLCBpB3UF2RoL3+CmeuyCXBZu5+G4ztN4a8V1Z93M4PPdyoVjJRJRQkQmNZuVjPiZjg4jjD4bhrT40Waym9Ts8t6Wp5dXnnyOS4BoyGcoL/Y8W+KSCsonCNosV+PPkpi2wfXG3fksmwpWqTjnoxAiGHbZ8FU0YTbu3icJFT/h1pBGN96NnhLHpCIvHEVnubzTJf7JNKGdXxAw6fV/5BEZwJ2Bwx5qs01vDglnkKBQg8y8+Pm6MJvkXO+z4+j8AtxAcfhDSkdWF/IPcVzHhkM2bJKL6G9GIiIOF1wHZ83JXQ+JEqd5rSvH/5Thw399agLt5lAXb5wTTuVn/dmgR5tx9kfvh89lsvP+/UYlrSlMDFdXQqivJ36ZwkVnplLCd9yHg4BNmSAzV58ZLEV2jg3pPukOeezfzmCJyTvR1qzul9Zne6/uA/6opQWTTb6NOBctWa741RTRdHSiRn7KZ+t7AVFftOIOilAsw3Jb9S/9B0ghwH5XJXwcUU6xBYGNfUerqX/fRwE7lrWuMpBUsxg+TggGGptCU5xC/xng4Ct+cFia7Xzlz1N84wjb3nEYcuiRE0TjGSgYlQEvVsdHSbx9UrCdpTLgfhg0yl7KAavmCYsWYmGz5O0wzHo/nyJs91PjTZVyelDirlRiUWGGEbzs7TWEpa0UGjy8aL0ACelxcf7AKjNvkVDJh3gi6VN+tCGjYxoEjRkXiZhTnkXnmoYIrbTGCh/BCKQ9IP3XXgua1TY2vkp1hJdL0SkcqI7c0cZ/WVHAQsgnGvl7q/45h3Es83Y4lHo+Uuz2JaPEQF33xqavRVmBoxw8cZX568riPbH9ecuEZO5d3u4eKwYsPXKO8krpeoQb7YUFeq4HsLyE qij86bBA 88NGptOZI+TKUsyomicyGpU5928NV3sG3gqrF64R+xJggo+HjApd7Joh9P/qLsYx1JnfrtPxciTbO09OpGuvyG/5S0laXaxNagaEGLO3iXsbnD9GkKNtYUqwiRO+FZ8z3FM/nxPBmmFYuSWQcrSaqjn4ieT9jgFTi4i6yqbnfpUz11JL8fdQtr1e8NMu0YTSEjqmDDj1KwX052gKHBUp3weiZ5g== 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, Jun 03, 2025 at 04:48:08PM +0200, Michal Hocko wrote: > On Tue 03-06-25 22:22:46, Baolin Wang wrote: > > Let me try to clarify further. > > > > The 'mm->rss_stat' is updated by using add_mm_counter(), > > dec/inc_mm_counter(), which are all wrappers around > > percpu_counter_add_batch(). In percpu_counter_add_batch(), there is percpu > > batch caching to avoid 'fbc->lock' contention. > > OK, this is exactly the line of argument I was looking for. If _all_ > updates done in the kernel are using batching and therefore the lock is > only held every N (percpu_counter_batch) updates then a risk of locking > contention would be decreased. This is worth having a note in the > changelog. > > > This patch changes task_mem() > > and task_statm() to get the accurate mm counters under the 'fbc->lock', but > > this will not exacerbate kernel 'mm->rss_stat' lock contention due to the > > the percpu batch caching of the mm counters. > > > > You might argue that my test cases cannot demonstrate an actual lock > > contention, but they have already shown that there is no significant > > 'fbc->lock' contention when the kernel updates 'mm->rss_stat'. > > I was arguing that `top -d 1' doesn't really represent a potential > adverse usage. These proc files are generally readable so I would be > expecting something like busy loop read while process tries to update > counters to see the worst case scenario. If that is barely visible then > we can conclude a normal use wouldn't even notice. > Baolin, please run stress-ng command that stresses minor anon page faults in multiple threads and then run multiple bash scripts which cat /proc/pidof(stress-ng)/status. That should be how much the stress-ng process is impacted by the parallel status readers versus without them.