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 E4FC5C5AE59 for ; Tue, 3 Jun 2025 14:48:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6BB8F6B0491; Tue, 3 Jun 2025 10:48:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66AC46B0492; Tue, 3 Jun 2025 10:48:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 55A136B0493; Tue, 3 Jun 2025 10:48:13 -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 34D206B0491 for ; Tue, 3 Jun 2025 10:48:13 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CC8A8120C7E for ; Tue, 3 Jun 2025 14:48:12 +0000 (UTC) X-FDA: 83514369624.15.02F6D28 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf07.hostedemail.com (Postfix) with ESMTP id C174140011 for ; Tue, 3 Jun 2025 14:48:10 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=R9MHPJsJ; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748962091; 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=emupu0FVoX0tEpk+sXqho1utvGRUyKk3cbcNI7c+Gpk=; b=zKzzYHkjbBJDTxqwwZ7IXGVRTxfNOS1msQ0qpklve9LB36aHZ592h22xC5SVk68bOXYt8e +Veo+BKJhzu+7caR6UghezEJbRAKWor+i/lhV1JQpsiIK4kaEvSh3QRY4jQLdGHaSxzBEf hXy75hAwZsDID6UxqRTqJHd8+ZPaidY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748962091; a=rsa-sha256; cv=none; b=YG9pwFwFNLQf5SAWKxLwhQblO/q0qBS0JJB279wq3Mbv3y0uOzv3VwOgjo8tKhO3Clp/rt 1cGRmn3fCHsb5NpKqSKyqssaC/frpcasSXb6D5+8538D709Xj7902S8dlPAJqwc/qyNDEW Dc4OuffpZOPPmjncRRX+UpQddUQbSoU= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=R9MHPJsJ; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-ad89333d603so1098360666b.2 for ; Tue, 03 Jun 2025 07:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1748962089; x=1749566889; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=emupu0FVoX0tEpk+sXqho1utvGRUyKk3cbcNI7c+Gpk=; b=R9MHPJsJImPY9GNyjzeGfl1zbrVXykOtMdq9FfK6feXb0mgVDOr/JQRl0V57UUtAFs zIakFTeWPSIarfHVhkebXKazNrgZYRIcLF4C2DS3l4VfQ0ekOtrxQLf6ubKGDkPG9PeA A+rcM97dY1WdM6h8JL7/Aw+z/cerd3CINwZFPINgHXICQ63obIdNzd3PvIgqvgFFcf/C J6rCRnkzr+mAPRtOI72EmuiL/XMdpUhcxqheNy/a8uK9v9VluCi/79nJE1PsBerAZ+9y 56uAGkaIAfHIoVZvVq9g8UEQHO502niKxeVrDj35LIy48ZjMRkc9uOPKOqNH0M5gV4mj NCOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1748962089; x=1749566889; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=emupu0FVoX0tEpk+sXqho1utvGRUyKk3cbcNI7c+Gpk=; b=eHGYsV/Y7UOogLbfJepzVb045kAwc1fgbGFbRscxyPjpDJfPmCnlK2LKctM8umCJnB llAwkNXtnLXbN1tyWWnbinpgrwK6SVtHyBk1uVk9S2TQboioirnz2ruK+zhpbgeSVZQ4 bmAKP5N/Fyva2OPH4CNAymd2923tVnY2LWWZPinKYTsFMyARCuWeG8pbKYpGbHApvUfc rnrBvuFIpJt9N+2lP5U14r/F9hAzk7wx61dktyOwQTV2Gn8+aaILAsMPTs2kj+msvdHV YsuemCUndLXXplMM+CUxoj4QzNQ9346DQypWppKKceGySR5hllLmNQEIdPCWH42c5dz9 soTw== X-Forwarded-Encrypted: i=1; AJvYcCXxa7pGdzN1CZe1WKHpAO5XmMt30Kpamh8gjunVq4bvp8nfKBsSctaAkMj/5BH99ennXaXGtWNdCA==@kvack.org X-Gm-Message-State: AOJu0Yy88EuR+JVmImvtDEaiYQaGMGTfU+owe435ZTg3ht//MuPmMVtS FOfhwEvieMsN9vlRf+dCYnazVhjPXLjWeY2JX55mLnxPrCFW1zlBONdSnpXhKPnTUtk= X-Gm-Gg: ASbGncutsM+wdU5fEudaLxAQZNcuhvuZ4sKm/JJrs0Kv82o5t/c/83YZZb8JMTHoZ/b TC5dErD9PtYb0IDMPYebm/ruWqUgkncqBt1bTBYOjKAEpVUgyrsuK3Qb9CjalsM8pjrnJTnZxpQ 8TDyVIG2khgFYu3CCPCt/5zjZEG61CFsYi/NkTKZy+aPI5yuL9bEQ9c7iws3uL5ZLijZ1/Rf7eq u2fKgImXMZgWb5tPzhHcXFjp5R4NiKj3OF+LB0W5MN3Y+CtyR5UE1S+/nAMybnPO1JTxAyqKzfg D6gcSUMAop08fHp98eY7yb5j56WF74LR7/AmyWh9khDroy31W5/I59Z1igbApyX1 X-Google-Smtp-Source: AGHT+IHMPk/E1wB5w3uEJOJyss7DVzc2lc08kcqumZBJp3zEJ80iGBcdVvuMoYieWZBFkdImcajKWg== X-Received: by 2002:a17:907:3d8c:b0:ad8:8478:6eb8 with SMTP id a640c23a62f3a-adb32248ce5mr1458814066b.9.1748962089043; Tue, 03 Jun 2025 07:48:09 -0700 (PDT) Received: from localhost (109-81-89-112.rct.o2.cz. [109.81.89.112]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-ada6ad3dd27sm952233566b.160.2025.06.03.07.48.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Jun 2025 07:48:08 -0700 (PDT) Date: Tue, 3 Jun 2025 16:48:08 +0200 From: Michal Hocko To: Baolin Wang 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 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: <7307bb7a-7c45-43f7-b073-acd9e1389000@linux.alibaba.com> X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C174140011 X-Stat-Signature: 6xz7czf6fjfsaz7d357n14bjedw5cye4 X-Rspam-User: X-HE-Tag: 1748962090-927045 X-HE-Meta: U2FsdGVkX1+6wiZnjc427aV2zsrkjEVTuydaJGELuRHippyvIPfc7bMGivT7M0d75+qBLSE4argRSyTf6LsnUS3/UQ1ooHGx1lwczJwAZ1+Bh+sqbLjz6Ua63Vvm86OsIT9ko90kLm39l0A2Bnl/hzh3UgWeAQ29N5RatXsy0T0Q9of1XemkmJNpjMow+sJeW2wtk5lPHA8s9v5so6Oj9ZDYLhtMSF6qAuEBqcW+VUBfsSLoElMQ6Ua92O/I+rRNvKdoplcQVvxKALfoKPP5vSC/Lr6a7ZU73cU/S85C0ZfquOwlHJ6RcIfrQilN/rD2EWLHuftyGg4wGfWHLyT+0f1eLtHC2aRd68rXvW/g3hy8X2NUdDLw+P4/BLbvzNbnAxMzT54qCX0braUaaYyUttS4XVOe23LczDkmTyhPzR3tRUAz1XC0ndzOhV2n+BtW1GpMLACqW1x4eUFjyM7J86KZcyR6kz1g7UQPau/dbevawB31DKkmaP/ZerD16aS2GaS8ErQBjWey+CPb5Un2GReSg0BfEY1BKT4s0xeDfUUWcAok1nyoExhgJ9P4Stg8I+AZ5VLvJj+2tsekHcTR65YlTup/kz2jq7hVgM68MeZbpFvMHkPBV1GPlOC1hLkEv8ipcCXOAkv2orHl2v+qS3ScGd1fZT49xqtFkx1QqR0A+/ov7ceJbdKc2oWNuyB0qeeUrH97/+1MDeFmRKTkYA8JpnHZazcY4NxhyKNsXGV7ZxTFItd82WIxYVn2Vybi+jytlxC0li8q7KwvIcE0cS/+Wjnf0jZtO8JnLo66X2ZS4Gt8UtFgkYdcnqChSD8T91LUdBj3qmH947i8Ma80v8LM/coJgIOW4aOazwvJy+hC7W6/V/kIz8Aw5jixXGzeQTtPlOhJBpq7N9yevyc7kHHs8zj9gWLG22q0y5pQhpZZvjPiIWYafN5kTcXzgOLBAFw5XecBcZmVW6f9tmi qZuO5No5 zgydP/SiJ5bGFgvuAE0GFonxHd3bWNj1jrl/c1BDcBTEhmgK7ID909tHNZ5KF5AqarJl+MEJm3FD3fziGA5UD7QLXSlrxUPvv2VD3Fx4x3+yxmxRM8oXcfgmZcOoB9ap2mjhxhrYPuIh9DFs0eu4LNNRn8zQ2rDuo5NknA/m6dO64pJuizrbStE+4Q8VZck62jXLOZpS7Af0qK6siae8lw9lmbxayb2BVf6P28xJT8tXpY5Yf0cdAErAaVHyzkT/elUsMObxm8C3OsbWIKWBGnH9ISIq8Wir8t/XVjEFBz6fXjxh3TTcfT9u8wDfKpQtutmH+ 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 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. See my point? -- Michal Hocko SUSE Labs