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 9E7A2EE57FD for ; Thu, 12 Sep 2024 02:28:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 359E96B00B0; Wed, 11 Sep 2024 22:28:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 308E76B00B2; Wed, 11 Sep 2024 22:28:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D0E06B00B4; Wed, 11 Sep 2024 22:28:16 -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 F1C696B00B0 for ; Wed, 11 Sep 2024 22:28:15 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6D8501613AC for ; Thu, 12 Sep 2024 02:28:15 +0000 (UTC) X-FDA: 82554501750.03.0D5EEA1 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.4]) by imf20.hostedemail.com (Postfix) with ESMTP id 8DB761C0002 for ; Thu, 12 Sep 2024 02:28:11 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=163.com header.s=s110527 header.b=O1EXxiv2; spf=pass (imf20.hostedemail.com: domain of 00107082@163.com designates 117.135.210.4 as permitted sender) smtp.mailfrom=00107082@163.com; dmarc=pass (policy=none) header.from=163.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726107989; 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=e6zkEQS3wj7QBN8oFubOcQpIMuqjGBx3aY/1Y2uIOJ4=; b=dDh7ixZhk6SOZ9gqZeFewXz/rmUkV0zdh3fWXHwN3htoBMy5ezLUd21jZdiMp0Ufn+xqvL yn6Az4AK+ahgvxfg9hI/d6QhRpVyuQXZQHPqWSBPFrHkLk1k0PC9zQZ877LLyMx5jQd0fO OmJJxxnFHCWqcynXKFy28fgnVF96zMc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726107989; a=rsa-sha256; cv=none; b=QCuDX5Y1gF9lOVIbXkG/VQeyY55wX7ojo8348q96E37ZAJMepEb+ACZREiM6Fl0AWHf0cQ 40VnorTBsGcUmQD7P7gu500hkbMnCFgD/YKhN51MLlG6rLhOzzL7ehybRUvgNSca99iERt hvom9pqaay90JrnlRKxKmC3TKnne/Qc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=163.com header.s=s110527 header.b=O1EXxiv2; spf=pass (imf20.hostedemail.com: domain of 00107082@163.com designates 117.135.210.4 as permitted sender) smtp.mailfrom=00107082@163.com; dmarc=pass (policy=none) header.from=163.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-Id:MIME-Version: Content-Type; bh=e6zkEQS3wj7QBN8oFubOcQpIMuqjGBx3aY/1Y2uIOJ4=; b=O1EXxiv2N3lrqcjQDxMSvhjLojapEp02LOpeNjauBi9izNpWci/dujuu5XoJPP 7k3G/GFRqMxIKjhmDbmIwYoACRIdZpnxdYnpkxp4Yvr2fy05ILtoKQoG+T8yVYS0 Z10wP6y2Q2FekPJfpwVjZQfW9drzmrDzh8pswYHHd5u00= Received: from localhost.localdomain (unknown [111.35.191.143]) by gzsmtp4 (Coremail) with SMTP id sygvCgBXJzacUeJmJglwBg--.45767S4; Thu, 12 Sep 2024 10:28:03 +0800 (CST) From: David Wang <00107082@163.com> To: kent.overstreet@linux.dev, surenb@google.com Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] Add accumulated call counter for memory allocation profiling Date: Thu, 12 Sep 2024 10:27:40 +0800 Message-Id: <20240912022740.6125-1-00107082@163.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID:sygvCgBXJzacUeJmJglwBg--.45767S4 X-Coremail-Antispam: 1Uf129KBjvJXoWxJFW3uFWrCF17XFy8Aw1rCrg_yoW5XF1xpa yrt3ZrKFsxXr1ktwnIq347GFyrGw4xGr15JFsYqry7uwnxWr1Igr17tr4ruFZ2krn7JFyj q3yjva4293Z8ZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07UhYFtUUUUU= X-Originating-IP: [111.35.191.143] X-CM-SenderInfo: qqqrilqqysqiywtou0bp/1tbiMxVYqmXAnzbDTQAAsW X-Rspamd-Queue-Id: 8DB761C0002 X-Stat-Signature: 6k3hbani8zzcft3i1t3hqehcquq9o75f X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1726108091-192784 X-HE-Meta: U2FsdGVkX1/mI2d+l2+DzdNNkHcKP3k1lGFeC4llGqH72U91tToONsHVrK1V08bt7ep6y1rt8TD5ZqrwTJSxkX6xCLv2sGZItnFRFZ5soEVS/JTaTGLX/ezu3LILd40w+hFs+PVMtAh8fr2eU5+EmbkEN5hnYYqYmy26aSvFmnS0v68fEgjkG77mtviixJOb3P8UVZUW2qXpiTf95AMs3qbqCA50We2eYFEl9Rrw/IJV4gv9b3O5PICY8rDYp95zzXDSpeNCdRAkTBY6SKSs1fx1z0eppKuMk/Xz+4O7AoqX9QREW2FDBr8ifwGpaXb1ss+/F72Gj4Gm2E32Lsbl6X9k28J91+OPs+UVzbbcAeIkrLMzAkjYwFWNbO3tIITanWCrzvgfhXBf7L+5uZoYzIlI48CuTulxQ6xbB0Pg8NuaMcmMCYiyuavNW0GyiKH1ddExztme+iNJQiklmsOIZr/cqZH15HwF0POZ45jV2xkAV3QnyEqq5yxDVy16Ws5jCY1t771a2qeCykvWV0hx6JkI2phW4DOAndcurN2GnK08id5sirQwyX4O/5PepA+4v+yGZFqQ8xkC4krEz6XJXD2kWSbesSLjiz1W8D/gp6hd6WZMqtlnDB0rnmmSkckDlspQx1YUa+sSrys2FKf+G/xkXBj6RnTONKP9nZUOO5IxZtAHIx3KncPG+MMKcV/DHSC/t3nZIbgsz2wgVIMCJPAveUZe2YfkA9NOad0p8REuxzQ9chfXGd0j1jLxasGMZX5ArMmI3GqSWFDtx3eZIASMN2IQD2X8cyrl1f5v9AgIsWnpG/UAZHrh8ZE9xcwu+d7U/B5d7vvj1Ow1VTRmbkeco8i2OrOFtlcH1RsOlTSiS24SgjIpKDtV1mchpYrqNuwbLVZPptDF4wW9Y9JJO5oKzav9qkaZVLIFGCTZt24VONxZCT+bjTS4OHLU0clFi1mwoWQxAy2Bs2c3PhK cKc6OZXo hfBHTNmSzV2Nl8K10a+yiu+H0w4p+xRnidFZuGGQjPMPzC3SY+ckWuAtEsdclfjCezyuz9MTpjYkaxg3yQakNyEPZxthmFldJANQtqUyrkHuqsn+0Jb3lnXzxR1H+nEVW5iRqLCRsH707YDVp7hN1Ov4DqHJlf+cD8EQxJSYFUB01WP/N7SvM8cf/V4YQyTWlWelvARxuesTIYjBeIxTfSOmIW+ydjdzG2/V2zvCX0HItDeRdTgOe9sF4BMXHKn5MGc/mp9zHRIH+X8cd7Yaldl6yCRmPzbo3kk7H9qRNPL2WWDMt74qGan+4RzjekfT8Qt2kaNVSbMWdrNRGuSCJ8hMS4oY2uXYGYrP+VhcvMrM2hbiuZiw+fT2PUps+PKYOhWpMml4/UzWBKF4bd5tcRpZ+TBxDim1+sC582CUZjSNr3CkvgHpEx/rxRURXd5lYcZLIuxwidvOI5KiG4Rv11Ddgw7WFl5oFsn2lkQakxoyy2I52fTIW7epFJLUJ0mhKpIIoTn4/E0eSp/MgqSsI7c2o7QmSVwKXa5M7MvPtr9Ac3uC3sjvgT3o0L2ex+lW4qWt7 X-Bogosity: Ham, tests=bogofilter, spamicity=0.027663, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: At 2024-07-02 05:58:50, "Kent Overstreet" wrote: >On Mon, Jul 01, 2024 at 10:23:32AM GMT, David Wang wrote: >> HI Suren, >> >> At 2024-07-01 03:33:14, "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? >> >> Cumulative counters can be sampled with timestamp, say at T1, a monitoring tool got a sample value V1, >> then after sampling interval, at T2, got a sample value V2. Then the average rate of allocation can be evaluated >> via (V2-V1)/(T2-T1). (The accuracy depends on sampling interval) >> >> This information "may" help identify where the memory allocation is unnecessary frequent, >> and gain some better performance by making less memory allocation . >> The performance "gain" is just a guess, I do not have a valid example. > >Easier to just run perf... Hi, To Kent: It is strangely odd to reply to this when I was trying to debug a performance issue for bcachefs :) Yes it is true that performance bottleneck could be identified by perf tools, but normally perf is not continously running (well, there are some continous profiling projects out there). And also, memory allocation normally is not the biggest bottleneck, its impact may not easily picked up by perf. Well, in the case of https://lore.kernel.org/lkml/20240906154354.61915-1-00107082@163.com/, the memory allocation is picked up by perf tools though. But with this patch, it is easier to spot that memory allocations behavior are quite different: When performance were bad, the average rate for "fs/bcachefs/io_write.c:113 func:__bio_alloc_page_pool" was 400k/s, while when performance were good, rate was only less than 200/s. (I have a sample tool collecting /proc/allocinfo, and the data is stored in prometheus, the rate is calculated and plot via prometheus statement: irate(mem_profiling_count_total{file=~"fs/bcachefs.*", func="__bio_alloc_page_pool"}[5m])) Hope this could be a valid example demonstrating the usefulness of accumulative counters of memory allocation for performance issues. Thanks David