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 074A6C3ABC0 for ; Wed, 7 May 2025 23:43:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0997C6B0085; Wed, 7 May 2025 19:43:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 046EE6B0088; Wed, 7 May 2025 19:43:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E515D6B0089; Wed, 7 May 2025 19:43:09 -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 C5CD96B0085 for ; Wed, 7 May 2025 19:43:09 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 9B9551A166F for ; Wed, 7 May 2025 23:43:10 +0000 (UTC) X-FDA: 83417740140.16.F08F911 Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) by imf25.hostedemail.com (Postfix) with ESMTP id E344EA0006 for ; Wed, 7 May 2025 23:43:08 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="OsL5iJu/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746661388; a=rsa-sha256; cv=none; b=IGYUBHIdzAYeAYwSstKLr5/hfGYrbfK8flE4bWVcUotXiXiqzvegLhqzzUkDORNHtS/L12 wThKy/Ea8Ft7R4/x+7JEdqxP20AasZ+WEmunyW+LWG5lN1ldUeVs1LdThiMyWZlm5wIH6n 3tmRdD4ASO05yX1huHoNYx+LEvbVxrY= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="OsL5iJu/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.160.174 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746661388; 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=BOVx+mbstwSQjksfievzVLRvxXrcGWGDr3j4n+GjP74=; b=MrwC0aWK7MMDEZLuZ7isrunbkYRr4kROw0TTspYlPAhfWc7ttwhi7gvG4P4Feurj2115I5 Y1beAKyTI/FPA2WQlfTha14dLCBGgtGFRkzCzcWSzdeCXzDawJhfrv6Ks4ip1rVEmBOK8V wRp0CtRQyYexhlsBUJJ8hU/IEsMC2AE= Received: by mail-qt1-f174.google.com with SMTP id d75a77b69052e-48b7747f881so85661cf.1 for ; Wed, 07 May 2025 16:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1746661388; x=1747266188; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BOVx+mbstwSQjksfievzVLRvxXrcGWGDr3j4n+GjP74=; b=OsL5iJu/X2cIb43u7RqXghS+DOqNEagIhVhV+/IclbHzHSbi/DdZ9seMShmDgi6mwo zaK8fmcvq/mwR8XSeF8SroUeUF7ZKDhiItMTsXCGTqxR5xvg7o2laJ4IUQ1ZS2VWj7NM krqDOVV+mSbv7aQFUOB1C3FrUgpj7sOEe2byuLfQsePhyL7LzozW+A3HQq8WlHDlRoW5 Zj0E5Bvh1X6I09H/NLPfmFT1U8T7SrGKFauhq1sFYeSs3sXA5bGkQUzTK+Kq4++7s428 9q41jyyceYiZhjy0byFoA4FijC0SJkrUQyBBVwSC1pwUAVpkRC19PW63Dq8poFQu4RdG hTSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746661388; x=1747266188; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BOVx+mbstwSQjksfievzVLRvxXrcGWGDr3j4n+GjP74=; b=a9Dmoggu/QVlZH/A6zd+pmNGVzSGuMuz2nOToUhl+E0icDmIAc52K5STHqEVkusd3x nbzTV78ftiPD6sLblg5+loAmRo9JkBlYvD6ZX7vNMa3TmwhPq+jvv4ccmnPkT0IfubYl 1Jsxjm+9jQE+PsgFR9wso8AWKpoYeNwCIyfHSTM7y4yId37sPZMfZCL8R5vSIJWpKLjP agXIg+oM6LEHWzCQXwFbbL4rTo4OEl2priAdP17JXhUpeEZvmRt9hnnP20UeGmWkhZWL GtGxa7E1ARyx6YXggFEHJmaV5zC3FCYQIRjWjBNtdxCXUSavZOg2B3/LC5JNwyOr/siQ xaCw== X-Forwarded-Encrypted: i=1; AJvYcCVdNw34/84OIbyONHvpClhmEyCULwfjx6xGY/7JPSKDW43qWJU/FbEj9clkemWbcqAANg8KsOiA+w==@kvack.org X-Gm-Message-State: AOJu0Yw9gofL+5X9zhA9XREuL++ecSVRZdW73rziMIAqN6/IWZUpksx9 qEccJX/QAZMYQqwwnDNzjtWAknnZtzOEeH1eiZmDr9tvUUNxG4LzoQthKKXsL9FHgfwUBaM0KsQ Rk24/pHiTWq4M03DXfRD9bP6z2XxMqVB1CcPqK966g1gvB6sC3bko X-Gm-Gg: ASbGncsJzBd4T1M9RWAgJCiazYJnbvx42XzLx4OM1ipvKceNl78gHImN3Qqzf0dmwUW nP5psbQpQV8TQeRgwd+hNTiIcQmC1cH+sl1kEJjV/LVYV5zKEuENZdYA48sYZesfz6J5u0XjGCz eN4MCMF7FoX5JPkvJhp7fvt9WiOXPC91j42b91LFtd8yiMfF0dyw== X-Google-Smtp-Source: AGHT+IEnxv7pwvatRQSs8Dxg5JQ2zMgAZEyFH5tmwq3M93x2nXKq48Crs0+g1Bps3Sn4Yd7zXe9Xs3PEmxp6zldctLY= X-Received: by 2002:a05:622a:44:b0:48a:ba32:370 with SMTP id d75a77b69052e-4944998bbe6mr1780981cf.10.1746661387700; Wed, 07 May 2025 16:43:07 -0700 (PDT) MIME-Version: 1.0 References: <20250507175500.204569-1-00107082@163.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 7 May 2025 23:42:56 +0000 X-Gm-Features: ATxdqUFoIFtfWlpUAbTer2b5WtCX9D4SM56f9Q1caVD8GzpXX_rm8TYOzuLRYsI Message-ID: Subject: Re: [PATCH] alloc_tag: avoid mem alloc and iter reset when reading allocinfo To: David Wang <00107082@163.com> Cc: kent.overstreet@linux.dev, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E344EA0006 X-Stat-Signature: aq79d7wub8ukfn53h66z5xpccsdx5to9 X-Rspam-User: X-HE-Tag: 1746661388-923613 X-HE-Meta: U2FsdGVkX19kCtdftEhzaYRKmj9B2jf6WZhxKHc898AcWSj2sZEMF13DbsnWjP7wJrP/9cCJjJLDnZx6Muwe2RAcOFz7B9scA+4k91mKweTjoZQjfjahiNzwu5Klle4o85I5S7Q/YWHBQ/kwiaB4+QExdqrp0g4l49m+tuBs/1eBEzIO6oJeBToRSSpyKvlUu5xAEQ3gGpo3gq+jU1zlcHA/j5ChcZ8ihHBZ9NvmWiabHv3JjkNE/Cbzme7in/3JvQ7/c5AulkEVj+YoNw33j/vaLFYa1zH9EoyFNpVh5WCh7VCWE0tNS16C6rnBOmchx13U9hZgAtZ+BW/03tlIdu8FUwulXibwnT7ktIkwj4Zv6xwxrwivbhhKzx2AbLlhQyIoB60fVSijR/IU2d+2SXXb4JQDR4dG1dm7ZCX5Nrk8to7FHgeAQ1D84sYK4H0cVGIh223KjXrkNS1H9ImcEA2EjBdRJsHCRifqblce0cGPZ8zAk5MpmA6ad3mhc/wAechd4hlHOUHupRfmO6716I4BqOggbU6+neK8TkAc1gTsuxWrKITF9ynvaESqLw+8iXOu62LimeW35BTlduXt+389znxrhW2lWO+46/jHAzaoDZEXRBRYdNucrOYHMLcvuyhGNoG9MYUVeLm1nnxIoGEyQxj8YZx+p0UqCkM+Rq8GPIUTCsQd5NNtpLDq01JhtO1b6OffDKgMIQ9dMPLP/RUeZ8XRT4sXmEHPV39JEd3YiofcN8UmkmKzHmhtGpzClY74piHoL94EPnleHLvt8ycOWY7tP8T5Og8sDxuJPx3PvB55fdYjMm2969+EFgUyWwamKLQ84QRv8EI0K9qlVaSh+iqGPzO+9O/PMPbtq5Yr9wUJ/ZiljOF1j5Lr0xOf3wlEq4p+pHhJxAfv+QIL4CM4wSLTutTxUe93bM8v4C2a0BerS37tsC7ogG4RlZCFkqj6Dsx2Ly/FjeWVhz9 NS6x++WK rHLjJ+/tlGs5SyfoJgKKktZIn9sc7NYKGLA6B+kvkbg7tAJgjdQ6g9EfIcAnzFHfHSGWD 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 Wed, May 7, 2025 at 6:19=E2=80=AFPM David Wang <00107082@163.com> wrote: > > Hi, > Just want to share how I notice those memory allocation behaivors: the cu= mulative counters~! > > With cumulative counters, I can identify which module keeps alloc/free me= mory, by the ratio between > cumulative calls and remaining calls, and maybe an optimization could be= applied. > Following is top16 I got on my system: > > +-----------------------------------------+-------+------------------+---= -----------------+ > | alloc | calls | cumulative calls | = ratio | > +-----------------------------------------+-------+------------------+---= -----------------+ > | fs/seq_file.c:584 | 2 | 18064825 | = 9032412.5 | > | fs/seq_file.c:38 | 5 | 18148288 | = 3629657.6 | > | fs/seq_file.c:63 | 15 | 18153271 | 12= 10218.0666666667 | > | net/core/skbuff.c:577 | 9 | 10679975 | 11= 86663.888888889 | > | net/core/skbuff.c:658 | 21 | 11013437 | 5= 24449.380952381 | > | fs/select.c:168 | 7 | 2831226 | 40= 4460.85714285716 | > | lib/alloc_tag.c:51 | 1 | 340649 | = 340649.0 | <--- Here I started > | kernel/signal.c:455 | 1 | 300730 | = 300730.0 | > | fs/notify/inotify/inotify_fsnotify.c:96 | 1 | 249831 | = 249831.0 | > | fs/ext4/dir.c:675 | 3 | 519734 | 17= 3244.66666666666 | > | drivers/usb/host/xhci.c:1555 | 4 | 126402 | = 31600.5 | > | fs/locks.c:275 | 36 | 986957 | 27= 415.472222222223 | > | fs/proc/inode.c:502 | 3 | 63753 | = 21251.0 | > | fs/pipe.c:125 | 123 | 2143378 | 17= 425.837398373984 | > | net/core/scm.c:84 | 3 | 43267 | 14= 422.333333333334 | > | fs/kernel_read_file.c:80 | 2 | 26910 | = 13455.0 | > +-----------------------------------------+-------+------------------+---= -----------------+ > > I think this is another "good" usage for cumulative counters: if a module= just keeps alloc/free memory, > maybe it is good to move the memory alloc/free to somewhere less frequent= . > > In the case of this patch, a memory allocation for each read-calls, can b= e moved to opan-calls. > > If interested, I can re-send the patch for cumulative counters for furthe= r discussions. Yeah, my issue with cumulative counters is that while they might be useful for some analyses, most usecases would probably not benefit from them while sharing the performance overhead. OTOH making it optional with a separate CONFIG that affects the content of the /proc/allocinfo seems like a bad idea to me. Userspace parsers now would have to check not only the file version but also whether this kernel config is enabled, or handle a possibility of an additional column in the output. Does not seem like a good solution to me. All that said, I'm open to suggestions if there is a way to incorporate cumulative counters that would not tax all other usecases that do not need them. > > > FYI > David