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 54110C71130 for ; Tue, 8 Jul 2025 02:05:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E58D06B02FF; Mon, 7 Jul 2025 22:05:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E09A56B0300; Mon, 7 Jul 2025 22:05:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D46396B0301; Mon, 7 Jul 2025 22:05:32 -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 C5AD36B02FF for ; Mon, 7 Jul 2025 22:05:32 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 66BAB59060 for ; Tue, 8 Jul 2025 02:05:32 +0000 (UTC) X-FDA: 83639455704.08.08425F0 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf24.hostedemail.com (Postfix) with ESMTP id 8C212180011 for ; Tue, 8 Jul 2025 02:05:30 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dQj7q1yl; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751940330; 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=Sh+9W+t3yFXX+ZenHlBnmgjEo/bRO2j4p99y+7ibeXQ=; b=DaCgdp4M1iNKR2DeOKS+m1l/T4HW/doJXpd0qxg6IlxfzIJHkqJzJiIs8YnBnKnpTLB8tF nbbNvy2QnNV4M1N95GpBc9uNQGMogQkUUbLmb/SU8zDBYrL1SEGw6EXDzTxfcDN7HhcINh MOAEijxzTlGIf92obYk2rzGSr0T8bg8= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dQj7q1yl; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751940330; a=rsa-sha256; cv=none; b=J4XtoNMWdz13uPTVNglmz0iOWuUx/Tv1godmTk2CKnJRyn6npr+0uRDfrK8bd95cc2z8Tm FTMz+uwQZzqeeu4znyaiYdEv4PBoxa2IQ7DOFcBb/nASlznkjYyMiIwlfLpejMJ45bQjwt SLPziSmT3JSlMsepzS7/g6B1TFflhM8= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-4a7fc24ed5cso118661cf.1 for ; Mon, 07 Jul 2025 19:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1751940330; x=1752545130; 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=Sh+9W+t3yFXX+ZenHlBnmgjEo/bRO2j4p99y+7ibeXQ=; b=dQj7q1ylG/5g3PY7srg2u5s/gJokCm0RkP4RT+r7IFwH52IkkEMOp452o+u1lJdPhw vl4B+TtxJ+15+dCfl3rIZS39zMk9SXlNF8W5vKzbu62Xuv6ziHvN5rCye37l1Zpbx9kn JSC/NrdLQcnYjTW/nxtRIBlbNDXcXipG+qkfqL+ko5GR1CFXh1S543oh2nJ7QlzV0/RI TwrGpjj1dY4/8iy4MGN7CCIi4sL+OH8p3GR+jLkuu2iEtcq3NfQtLadvwwZT7F79I6Em 3DFVozUOPTW+l+mlbcV3W+YuxIf0sFyMSC+Ts25WlzRJWDVql0BT07NlgPyAyQwKaP5P 9ctw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751940330; x=1752545130; 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=Sh+9W+t3yFXX+ZenHlBnmgjEo/bRO2j4p99y+7ibeXQ=; b=rU9v0JoHHFSeb3K46yNuSTyhupdm6Bqsy0MweQPAeWLaJruxcVQWJwUVGLxEzOG8u6 JJnpXoeV4A7BofBk9W7T5w6/OKTHST32aBI3wWaKUtsgVW1sYfplVrruiF3cpjxSijTc 8pcBUeCFuDHmnOYYdCUTm1NqbgAyIPJkeYMIjr4HTIXeW1KqlwDbfmHvQuggvi4QFeZs XRgr2H29PwVq1OjGq1K5H2WpjmPiIMfGXKT347R5+LAJQi2EfYqzcx/3kIuDoVeZLUo0 8ZJYCOnP1K9t3QTzAJoHl7+c5hkqv/xCdAHfthNRJPv3u4MHdREzKvgL4WIWwW7irtkS lXig== X-Forwarded-Encrypted: i=1; AJvYcCXS0p6GtrcVV3A5t2mDV1FtMmjUavV8PMc5EF/whvgwP2yN4RPsTL39nwMfEJElV8zp9ISZLb0TXg==@kvack.org X-Gm-Message-State: AOJu0YxkF0fDWoANN2QJy5nN6uPtV2CrEn7y7OlR6Q0XhM5YoHTAPM6N HjBLilrNbxi/KOZjcPf6YPrYW3XmZpQOSw8Fkczru0d1ntbtKx5n4ZL5sFbxlNjXIshk9BhLs9P lDTb6BuYukFMgHrYCnCh3x8BqdX69CmpNeT3pCWhlCoyK5bhBQMFO4dWb X-Gm-Gg: ASbGnctfiJt/slzkOkYvsqWX34Oi+2B4tpfTwpEQnizzLmaRSh3xQiwv2xKiQ5FkQBB ECsrWSZck1J3viIvvz1QeSV2NZ+ip9UxzouGvIFgsN89fOoPO465kTz5cNsk01zCdobQwcHbZV4 TJnLqR+stFbkymJmUXxYF5Nf450MiCP2Nh1rePz4vLJom0455mNz29 X-Google-Smtp-Source: AGHT+IHRbBTLrwjPNdOAnm28xUZ4z3TqQGdMhhXns1JdU1VeHcHMXRH2gmYyy3q+Ev6CIyShbJU842kratQdKcig3nA= X-Received: by 2002:a05:622a:4acc:b0:4a7:ff6d:e956 with SMTP id d75a77b69052e-4a9ce65d471mr1187151cf.3.1751940329365; Mon, 07 Jul 2025 19:05:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Suren Baghdasaryan Date: Mon, 7 Jul 2025 19:05:18 -0700 X-Gm-Features: Ac12FXwj7mgMg-PEYvCoWp_GdWYSiJ--94zJ3-hBG3tjXJf6KN6YuR_PfXTY2vk Message-ID: Subject: Re: [PATCH mm-next] alloc_tag: add total bytes allocation information To: Kent Overstreet Cc: Li Zetao , Peter Zijlstra , Ingo Molnar , Steven Rostedt , akpm@linux-foundation.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: msc16nt8wspehn7kqpxmipxdfo7rajpe X-Rspamd-Queue-Id: 8C212180011 X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1751940330-907222 X-HE-Meta: U2FsdGVkX1/gCXONNIOBMMj1UcfgUQ4B6EuoM6/KjXG0zLIgzpvtwIeB0Sr/Bt6xtCkL9tloIsEEzg9A5jybIdTHMPEgEiLzZ855tkhn+GFeBkmGRvGtTFT672Q6X2eCX3TAcwsG3qk8nscNW6OVXv6180BUn8lmoOMJYgqKp/MoN2F0gqjjrUUf6CO7c3+N7YLEUHI0jXF0wTZEB3lF3ykozJE8/t16scd8Z2/QistfjPjwMVxvdiRqdThuItjM2H/gF82XpcYOe6Ci0BJJIdPwyygFjctI22RI4OpJPD32OBYxWyNiUwdEM56y9CrF9L380cbzKbHRIl1o1ET5JbjNAZlmmITrdimtokansqBzQyWzTGWL8HEZuHxl/tGSIgegSNm6mOqHzxpc/j/ryT9h5QlfqRPt3y5LhqtXvoVYPp/rZUj92rEuEUc/tAZLNITh19SUMMhD6dA/rdQ+rz8BNV+a5ENfZiI6/WXW4GnOtpN/1WSdB6rNHKDR41bUQyJ3rbwnwUyV/R5maBeHovGBcINAIYiFxoYzverfj3gUXGHzqLjRofxpJlHjJQI8QpN1ZpQggQfsF0XW5/7y26KIcDvveEyT771bnZKDpVK1GX9yM3Kl3T5GH2YvoXmNO8k/EKhN1nHWegcVqQTCABZzN8btapUCBzDrdiqLOERSMh7mxjvYKh2gmZmR3UGbwRH6vo+Sl46ng25tfoFJWEC8i6yiHOcBmqH7D6WJxbZ514eOj30FZSu+xO2sCAzzAq2jyEfJWPJv6KSNGG8S63UWs4NMCh5ctR/9dNSAT7U33DOIukLdQPdjsXgM/6ufvJ/bcqmvYqqTxsXEc9jai/SpEzuHd22z1Tj/lc/n51cFP1W1IS6aT8Xeir8igntvsYOMyJFg4KKgZJR2/CLTjHHjsxyNmwFdNP/IpvfCAjcrKnFCcNGAX0vvsDCr9Z+j3UU5xjuI/vBUo9XGKWd DIHw2z5f 1mLJXRjDf42BONdtrNySZfxox59vBsjdht79alBxncHnbZDl4kYm7KTL99eQAYK+0redFj/gSiTy7mjbYZ2lMc31TwUDjahc2Iv6Btye3oyFicp0JUya6v64YYG60KWWkbY7LhFd+bLUlw4mJ0Ono3HrVqDg4f83vQlg/X1/UipZSrzYLiq1zRp6scDiATrbwFdYJMHIBwSPtx8Yo/7vVvuNS1zAoNeMcwBvStJw0U6jYCXB7egIIrVcl62RoYK9U23ehrqEib9/XX1H1BAHIsY7gW6IVh3Q4Vt2ukCW/ubQ5iNxxdPZtuF+jbb+OzZ5mCE+YIdUf+f8+NLEZzrMMLYq1KT63UmjCOuWi6m72tB4iJFIBqBN5y46YqA== 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, Jul 6, 2025 at 8:21=E2=80=AFAM Kent Overstreet wrote: > > On Sun, Jul 06, 2025 at 02:01:41PM +0800, Li Zetao wrote: > > Hi, > > > > On 2025/7/3 1:14, Kent Overstreet wrote: > > > +cc Peter, Ingo, Steven > > > > > > On Wed, Jul 02, 2025 at 12:38:06AM +0800, LiZetao wrote: > > > > From bb3537ee638ac80eebcfe9160961e36df8d3ee4c Mon Sep 17 00:00:00 = 2001 > > > > From: Li Zetao > > > > Date: Tue, 1 Jul 2025 09:30:16 +0000 > > > > Subject: [PATCH mm-next] alloc_tag: add total bytes allocation info= rmation > > > > > > > > Some performance monitoring tools focus on real-time memory > > > > usage anddisplay the total amount of memory applied, which is > > > > convenient for analyzing the memory usage ratio. > > > > > > > > Added total information in /proc/allocinfo to feedback the > > > > total amount of memory applied to the user. Example is as > > > > follows: > > > > > > > > root:~# cat /proc/allocinfo|tail > > > > 98112 168 lib/radix-tree.c:338 func:__radix_tree_prelo= ad > > > > 12848 22 lib/radix-tree.c:276 func:radix_tree_node_al= loc > > > > 300760 515 lib/radix-tree.c:253 func:radix_tree_node_al= loc > > > > 0 0 lib/xarray.c:1214 func:xas_try_split > > > > 0 0 lib/xarray.c:1059 func:xas_split_alloc > > > > 208488 357 lib/xarray.c:378 func:xas_alloc > > > > 0 0 lib/xarray.c:344 func:__xas_nomem > > > > 0 0 lib/xarray.c:341 func:__xas_nomem > > > > 0 0 lib/xarray.c:309 func:xas_nomem > > > > total: 102208196 Sorry for the late reply. I'm trying to understand why this math has to be done in the kernel. Why the userspace parser of this file can't simply read the file, calculate the total allocations size and report it? I don't see the value of doing that in the kernel as any allocation size can change at any time even while we are reading this file. So, if you are concerned about correctness of the reported total, it won't be any more correct even if you do this inside the kernel AFAICT. > > > This makes it harder to process the output (numfmt chokes on lines it > > > don't understand, which makes the header a real problem). > > > > > > Given this and the per-numa-node patchset, I am inclined towards addi= ng > > > an ioctl interface and a userspace tool to do the processing. > > > > In my opinion, using ioctl is not very convenient. What do you think if= a > > file like > > > > /proc/allocinfo_total can solve this problem? > > We definitely don't want to dump more stuff in /proc, no. > > There have been multiple proposals that would dump more stuff in > /proc/allocinfo, and we can't realistically do all that with a text > interface - that needs to stay stable and simple. > > A userspace program reading data out via an ioctl will solve all the > things people have been wanting: > > - Someone has been reading data out at high frequency for logging pretty > graphs: we want to avoid string serialization/deserialization > > - An ioctl is easier to make extensible (unless we want to go json, but > I'm not sure the kernel is ready for that...) > > - and that gives us a place to add commandline switches and arguments > for displaying the data different ways (like the top command). > > I don't have time to implement it myself, but I can guide someone and do > code review.