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 334D6C27C4F for ; Sun, 30 Jun 2024 19:53:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29ABB6B0088; Sun, 30 Jun 2024 15:53:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24B2E6B0089; Sun, 30 Jun 2024 15:53:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 113466B008C; Sun, 30 Jun 2024 15:53:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E802A6B0088 for ; Sun, 30 Jun 2024 15:52:59 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5614C1C2B28 for ; Sun, 30 Jun 2024 19:52:59 +0000 (UTC) X-FDA: 82288603278.29.A4FDDD8 Received: from out-179.mta0.migadu.com (out-179.mta0.migadu.com [91.218.175.179]) by imf18.hostedemail.com (Postfix) with ESMTP id 14D031C0003 for ; Sun, 30 Jun 2024 19:52:56 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Qb4jgR/M"; spf=pass (imf18.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.179 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719777167; 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=Rl3FZxzTv6nkUMASAYvw9B8a5YZiWMBa7RB0BRu1rRY=; b=q5GxJKqL6yD9KlA439/QvnDZOLkRLJ/OjcOtBIJeXs2DhniZaGEbg5zOtJ4RY0wg1caXlY AmQZWM3KcwW/WtG0uEDVmROcRWcOn24xr+vi8Zi68mq5946TfXb1AZFohiTJqfBfrJQU17 mEroZ+tQy4+pQAs+UqY56AKqEeovYTc= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="Qb4jgR/M"; spf=pass (imf18.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.179 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719777167; a=rsa-sha256; cv=none; b=wRlEJn1EYIEtD6MPIgDFaed0JG9ahKcUu1MoIXkPOttFBjHK4T1K5q2IJm9U52MIA0T+Cm smorgucn9KSROhu3N1zfCU8nWjHvVQ5O4SK3PGG6Dgx5A3domB3pXQpnXJGAsUXngas+x+ ijSAAcCsT5OJxJQZQH/WM3OP369xERs= X-Envelope-To: surenb@google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1719777174; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Rl3FZxzTv6nkUMASAYvw9B8a5YZiWMBa7RB0BRu1rRY=; b=Qb4jgR/MtNRK+7bUH1C4JiDr6rYwpc54H/vo3kvIVx36HKB6OlJPcwCKrkLorjp+HpqPid iDpzITqlK083JXmw4t04lIQ+aWf8AG11rc8jnk1uDiubhEyGSSTNvh4NcQ94z8ybCyEBEb 7cQLuac+4BJWiSbSFJgKCouzFY1fSrc= X-Envelope-To: 00107082@163.com X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: linux-mm@kvack.org X-Envelope-To: linux-kernel@vger.kernel.org Date: Sun, 30 Jun 2024 15:52:51 -0400 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Suren Baghdasaryan Cc: David Wang <00107082@163.com>, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Add accumulated call counter for memory allocation profiling Message-ID: References: <20240617153250.9079-1-00107082@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 14D031C0003 X-Stat-Signature: 4kr38w9emyk3w8mjjp69o75fma4k4xgu X-HE-Tag: 1719777176-209875 X-HE-Meta: U2FsdGVkX1+nkqCzen/XMFhz/TFGsgpdqwOgBLWxVTds+jgAtypU1aKM0NofzAGYN7Y596fo/pgGGJ+WFX0Gkt9wEQmul1K2NeKMJbxRLLBCPhhid8FLeiwy2D+y06WQTE2s7RVzCqg7m1UOrPfrD+CrnpWwV3WQXyLruXuXwSP3K07rpMxfxdH49NmGPqKCa1Pvzl4mS+zQuWWd8GXQ5i8Fk/flsMsDUx6k5tiJqJVfo+gDMgkuNHrBOIdlJ2do7iF4j4WkHzfcq9cWoW7Ki6NNQk7jo6PM9OH2lpPQzEYBsSprptq6aa+MPZV6HTBO3QzkjgBCS9s0gbl/pMArkCpUFoVpy2lesBVxETmDmQbdvP3TgBtaO5UigvLz+0fUAQocgw9zv5bx+fWpJhU2k23fTp22/tbYkfO9RFnuV7kqvZUjhU6FUVQ7kCum/Ay/y3+cFK97A23lH6eKnVfqHc8kj9gNCcLxM6zgKn32CU4pXu/5B48LC1rsw6uQ7XYWbVGVQRVypCxZyc7N4ZcFNqAw2Xuwuj7rTKCPF1NAG6oVvgcdO0K4qNaJD0/z1n8cswpXbmVO0cUv8Vqo21sj7vmVRrH0XIEEyFwZIxsidudLPiusYo7pKfalMckzFkd0aYGNW/wDyhKpBzN+9PQAcW9o4GHPIHSagclF/iYAS2/cSadLAWUlwK8o42q44msLIWQAGGUgJ9Cha7Rk95Qptmq1zFh1Q42OJG9rBEG2/59ZgbJEmll1l02WdfQpnd92mUK5j/l5iKTcP88qp6pNe9kn4PmB/VI4jDsmAcphty1XGO0b8xnwOzuCzLCSXxjSJxo+BmXc74JLhC6B46qzLyTGD3lS6W1l8lVK1VK6TEmzSSyFggg7QHLtSorVrq2nXvBtH0D5OAiiFywJzYmzApit0CEHAsIaBJig+7mVf9wURcUWENWrNARx6eqk5mtGuAYwsDREWJKwgNOW8Zb KUMXZP0w 807IPBG07u4uyGIYqUaVSPQoT+JZVCDQbhcbKwJtT61jmypzf8F8BmykX6w1GnLWw+lP5j3qmtUGldII3vyfJpuRCgNUqdyu3EVHwpocqIUI3TAuHkENESWpifRdygYWNDhYTc8PpEVMoXly7C0FotDolrRKPQUobPZwezB/LmbC4qx9fJf9GZKhqNXqw+QQLl7FljYacPLjgQyFd1OX2DW03EKVCb5DStVTvAioEBGoMy3tic5J/uiFOU/jfTox/tCf7 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 Sun, Jun 30, 2024 at 12:33:14PM GMT, Suren Baghdasaryan wrote: > On Mon, Jun 17, 2024 at 8:33 AM David Wang <00107082@163.com> wrote: > > > > Accumulated call counter can be used to evaluate rate > > of memory allocation via delta(counters)/delta(time). > > This metrics can help analysis performance behaviours, > > e.g. tuning cache size, etc. > > Sorry for the delay, David. > IIUC with this counter you can identify the number of allocations ever > made from a specific code location. Could you please clarify the usage > a bit more? Is the goal to see which locations are the most active and > the rate at which allocations are made there? How will that > information be used? > I'm a bit cautious here because each counter will take more space and > use some additional cpu cycles. > Thanks, > Suren. Maybe behind another kconfig option?