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 65296C47DA9 for ; Mon, 29 Jan 2024 11:51:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D35496B00B2; Mon, 29 Jan 2024 06:51:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CE5D96B00B3; Mon, 29 Jan 2024 06:51:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BAD716B00B4; Mon, 29 Jan 2024 06:51:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id ABDAB6B00B2 for ; Mon, 29 Jan 2024 06:51:41 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6ADC040999 for ; Mon, 29 Jan 2024 11:51:41 +0000 (UTC) X-FDA: 81732184002.16.3674ED1 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf21.hostedemail.com (Postfix) with ESMTP id 879F11C0016 for ; Mon, 29 Jan 2024 11:51:39 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of alexandru.elisei@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=alexandru.elisei@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706529099; 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; bh=fLY+wlYUqsxtnUrdfayxN74bhmGPgltzYIQSFxTmsds=; b=kpdnl6lNJEZPES+la1IznrD36uSx1muvKpJs36nUKXnCZJ3Qfe1YJPTFdbZYRWPllj1QXU QXQ4IzYSJjSX79oFeoXcuu1bolMajPeow8db2hSjQP+1sUAZF8/g41pIB+hu6OFE0g1SZ7 TpceTGWVYr77Q9ey3CvsHGri6xQY9HQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706529099; a=rsa-sha256; cv=none; b=pR0Cxm6FTmt7ztacunBRysx6ryI779iYHraHqpLF1ueUztAsRYVUBWV3r6wET67XrbUpS2 aujUO9U2vWxLFDKbT0L1MH4Z3Uij/Ezi8fcYMkBMGloibf1l2AP2d6wQPEbcfc243hnY/r 7w7/3qpnvL9byQllpzabxl6DoeoDvT4= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of alexandru.elisei@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=alexandru.elisei@arm.com; dmarc=pass (policy=none) header.from=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7D31E1FB; Mon, 29 Jan 2024 03:52:22 -0800 (PST) Received: from raptor (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 407943F5A1; Mon, 29 Jan 2024 03:51:33 -0800 (PST) Date: Mon, 29 Jan 2024 11:51:30 +0000 From: Alexandru Elisei To: Anshuman Khandual Cc: catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, arnd@arndb.de, akpm@linux-foundation.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, mhiramat@kernel.org, rppt@kernel.org, hughd@google.com, pcc@google.com, steven.price@arm.com, vincenzo.frascino@arm.com, david@redhat.com, eugenis@google.com, kcc@google.com, hyesoo.yu@samsung.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH RFC v3 06/35] mm: cma: Make CMA_ALLOC_SUCCESS/FAIL count the number of pages Message-ID: References: <20240125164256.4147-1-alexandru.elisei@arm.com> <20240125164256.4147-7-alexandru.elisei@arm.com> <0a71c87a-ae2c-4a61-8adb-3a51d6369b99@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a71c87a-ae2c-4a61-8adb-3a51d6369b99@arm.com> X-Rspamd-Queue-Id: 879F11C0016 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: dskp9edib1inctwsbfp6irfe5hc7fh5u X-HE-Tag: 1706529099-606936 X-HE-Meta: U2FsdGVkX19ZyKgtGv1zYas0O601mrg5SnujbwzFctP7js4YZxVsxqk/cSL+iU+UKsHo4auvCIEmARl9gdp5zYbVaM9VWBwwpbME+PZm0lZYViI7ScZ71dZcQReBIoTyD3F0uCXD9T+AlDFzVsZAlkmMoPmxDMiAbMMf+gjvq9UyV3m4bBYNxpY+9NouO03M/5x9/FsyZFmZMdkWiE9JSGPQW5ZJOwcxARmgizR74esIYk7fy5eBc5xr9zQVjvPxHn3piW5bl2Db5ZI2nk9u+DeD6ughIHaXtzNpTXYtPk2iAFplOw1nDYSMT3kixYWnceb5fIFaXdFiXSxuPstlG8FDYbqOw7kKr/XiZfhs/79c+s8fse5ZOmUDumev4zqfCrMC8l3XbHIgiiYMHJ1+0CzX8/R0iuYb6DcJHm5N1JkSyZic269MSGv/k56xtty0lkyAvc/98FRvcY0lbaw634EbR0vZf/HnkbC8K9c8CmwTW6bD5k0vH9eG5TQgBxDDPmtCgZQ9bHIjCi/N1qkhywXGCO9uxz2ahDpAiKsvxqc01O++Yya6jmEK2JJ4tN4pAbMs6gYZPGIjdf3RyRHz7l3Cb549D9it+meFmhkT/d3sEtLSpxgayZ5Rh7Ddm/YRg+B806/miTwo0kW/V1ZWSXOIUOZuxRf0TTyu8RT41M7ZLEK3T9rjEWmWCxSEyHPLRXIePfKj9BLqnytYJG7qOUkBfwR3l9Jj6Gphd2RZj56cwZhbWkR+YPenp1Owfz73QQOa34xDoBMHYLxMn9SeDLoHDtyeT3d6rkByIKOAo6zikBuHUEcvPbt4LT/J3mK/GVXSyN796HhPhLs/VLX/UG+jrZFQLGz0h9+TuLDdszzljoxcEHR8VlTLJdPbuns88VxS9cUTxkBDWWGJ4jskVXKJBXgIiDBa/cX0sbCBe+K7Aw66yDy5xGaqAfFh7Sqrqrp9azdRRhbWMF1luF4 /3qeSkKy /jK48WdSc7D4u8mrYbdH2HpvKTgqmcQaXlRJAxDrlLUUj4o2PtVVUzFFctYc/89SoZwBUuof3yOzrJyxSUR0O2Vt2Z6lWuK8oXfQ6xopwKeavUKjuC04/1Jf9SbqyJe0Dyi7o1TmspzLj7XairPOuLbQjZS30Cf+a8lXB1GwyggZaobmdYsci/perBee1vOCJ/E9nAl9VubendUEjmkJ5qBnUJg== 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: Hi, On Mon, Jan 29, 2024 at 02:54:20PM +0530, Anshuman Khandual wrote: > > > On 1/25/24 22:12, Alexandru Elisei wrote: > > The CMA_ALLOC_SUCCESS, respectively CMA_ALLOC_FAIL, are increased by one > > after each cma_alloc() function call. This is done even though cma_alloc() > > can allocate an arbitrary number of CMA pages. When looking at > > /proc/vmstat, the number of successful (or failed) cma_alloc() calls > > doesn't tell much with regards to how many CMA pages were allocated via > > cma_alloc() versus via the page allocator (regular allocation request or > > PCP lists refill). > > > > This can also be rather confusing to a user who isn't familiar with the > > code, since the unit of measurement for nr_free_cma is the number of pages, > > but cma_alloc_success and cma_alloc_fail count the number of cma_alloc() > > function calls. > > > > Let's make this consistent, and arguably more useful, by having > > CMA_ALLOC_SUCCESS count the number of successfully allocated CMA pages, and > > CMA_ALLOC_FAIL count the number of pages the cma_alloc() failed to > > allocate. > > > > For users that wish to track the number of cma_alloc() calls, there are > > tracepoints for that already implemented. > > > > Signed-off-by: Alexandru Elisei > > --- > > mm/cma.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/mm/cma.c b/mm/cma.c > > index f49c95f8ee37..dbf7fe8cb1bd 100644 > > --- a/mm/cma.c > > +++ b/mm/cma.c > > @@ -517,10 +517,10 @@ struct page *cma_alloc(struct cma *cma, unsigned long count, > > pr_debug("%s(): returned %p\n", __func__, page); > > out: > > if (page) { > > - count_vm_event(CMA_ALLOC_SUCCESS); > > + count_vm_events(CMA_ALLOC_SUCCESS, count); > > cma_sysfs_account_success_pages(cma, count); > > } else { > > - count_vm_event(CMA_ALLOC_FAIL); > > + count_vm_events(CMA_ALLOC_FAIL, count); > > if (cma) > > cma_sysfs_account_fail_pages(cma, count); > > } > > Without getting into the merits of this patch - which is actually trying to do > semantics change to /proc/vmstat, wondering how is this even related to this > particular series ? If required this could be debated on it's on separately. Having the number of CMA pages allocated and the number of CMA pages freed allows someone to infer how many tagged pages are in use at a given time: (allocated CMA pages - CMA pages allocated by drivers* - CMA pages released) * 32. That is valuable information for software and hardware designers. Besides that, for every iteration of the series, this has proven invaluable for discovering bugs with freeing and/or reserving tag storage pages. *that would require userspace reading cma_alloc_success and cma_release_success before any tagged allocations are performed. Thanks, Alex