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 06598C3ABBE for ; Thu, 8 May 2025 16:34:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 274DF6B0099; Thu, 8 May 2025 12:34:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 223B26B009A; Thu, 8 May 2025 12:34:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1135E6B009B; Thu, 8 May 2025 12:34:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DC38C6B0099 for ; Thu, 8 May 2025 12:34:38 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2CD0B1CE328 for ; Thu, 8 May 2025 16:34:38 +0000 (UTC) X-FDA: 83420289036.01.43E7C62 Received: from out-172.mta1.migadu.com (out-172.mta1.migadu.com [95.215.58.172]) by imf26.hostedemail.com (Postfix) with ESMTP id 31B9314000B for ; Thu, 8 May 2025 16:34:35 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=DlemoKH3; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.172 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746722076; 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:dkim-signature; bh=a4hSZ0K6uJrvq6Ti/e+NJ8QJtg5YKHaPqRm48p1ZYLY=; b=vbRulXUD9wA3RmnEhPzQDN+3nn6NWdZo6NsuKJlo0q5OG8ppWkFLQAW4viRTin+SN26Y4k /FRjcx2TAvaNQcq9ebikMnTPSssRsYiDEvRqp5Bm0zxCaw1+BUzdX/h9VOV7avEaxwJo3Z EdokPAEBvHf61iTyLagi6RiUnmiSV4M= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746722076; a=rsa-sha256; cv=none; b=JNleiS1hBmAARX0G9Q69hhpoeYHbiiF7P+qx3R1KcbTSTb83NKtvLYP8DtNjWyi/BIBBkU q8v7PCXJJSL7CETNQ5uKQKXd980+aUXCDlK9tRayqmVKkOKmIFrAf5O/78l03GwLzPfu9+ YlwZYtB6t+NcE1kb6SHXay8GwIFwYBw= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=DlemoKH3; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.172 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev Date: Thu, 8 May 2025 12:34:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1746722073; 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: in-reply-to:in-reply-to:references:references; bh=a4hSZ0K6uJrvq6Ti/e+NJ8QJtg5YKHaPqRm48p1ZYLY=; b=DlemoKH3T/1Fsf4HHMxoUSKWWwqeUpi4f1L8wOZS3oFWTaeI7XK7rexC2yfq4Hzc47mFdn +LE7WFx3IDpH6zmC6EisYyEp0bugsAB/SLxvubobpgkiIlDfgbM5hlC1llLRnZrFD++qbz p6jwWfgDAWCIgDnIDMv29PXDVe5gglM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: David Wang <00107082@163.com> Cc: Suren Baghdasaryan , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] alloc_tag: avoid mem alloc and iter reset when reading allocinfo Message-ID: References: <289b58f1.352d.196addbf31d.Coremail.00107082@163.com> <1ed4c8f7.3e12.196adf621a2.Coremail.00107082@163.com> <52tsrapmkfywv4kkdpravtfmxkhxchyua4wttpugihld4iws3r@atfgtbd5wwhx> <7bf1ee37.b6a4.196b0b6dce1.Coremail.00107082@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7bf1ee37.b6a4.196b0b6dce1.Coremail.00107082@163.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 31B9314000B X-Rspam-User: X-Stat-Signature: zbkx1bbnybntkrjr94bqqzcxytjpgpkq X-HE-Tag: 1746722075-955223 X-HE-Meta: U2FsdGVkX18WMAuLjmDKuynbl3wjTmt+GNvK9ZbT2RUlgO9aA+2k5jVDRFhL0/rJo6WbURP9S6Ox2obWCVK16Wk28bw6WoPtvZlWOmF7XQ9DTrFZYAliyUY3TPmP5+3xJYVZ5uTO6s+0ax/0Q96qgDOvGFvEQF5tvFHJUCteQpPMRTUmkjdwac9l5g/CHjPVmblO8H2X7kruYxVBn74atHDsuk8df2pnAP2K6ZGToFQnRL/wm09jB8F+Db0PwWHXyPWuDJM+9SliPm2weniVLyMvvsCZ/73shPXGgPEnW9Vb7sfHexr0ZwR7DOZ3U5+zbioNi1n/8bF8ODSFF4BANzdwd1DR6p9EAeIEswfeRH0A5De52vxzVJtqfH15Bpfcz1c/1NhlJ2g75lHBARL24YHyKTL/ljKtV+UORXJ/1h4j/W+JCgKH68HTEfyiio6kyh331aJ6DigEJgFkMPio2mPIEPApg0Xz+upwavq28fnl5P+tib5BUfffBETOGhgIMed9mhI/Wfyay4mYA0t1kz+2C17ok9LGQMvsHKVgOh1sTVSx1a7IVoiD8IPsb73CVJNl99vJ+LRYXR3RQCTv5g2LFIeW5OkuGfJJ9zWaYdB2opqxyRwEu72LrFRsa4K+AiMcf/mnAslzTwFBitTcR4IcvtoDabxp7dfOsxKcJz/rDuIgYdks1rr8/mAhm62JbIdDEFmSj6ETE/jg8/n6TOEbgc6IZB+zoTQlG8YyoJ0LeoONnIvsr+isNNZRcbgsKtZ6HG1waMikrnjPD/2S1F6yYizXdCZeztBaBPuhoqclriXgseSY8s7fx+D4oIVg4pH7112JJ/VIDQwGzCVEZMgo9VmqT5vKK1p6WhaFbTlcHmZk7v9aO7+UaNuLGBXSAwBw1SvdOs1wvhYSKYiGeqH7FTLj07RB3t8YSFMtgnKhN8Y0wdaM9aThI5tz4G6Xet/u8PlyyRWEjQP108M EkbloJ9w yvBCanwcUR8WI/CCIJQnTqS3d0zI0bSp+aMvQLWQspfUp/cFlM+lhUKutdernNX4Xv8/8NwRtFPz/Y3uR6rbnGoMgzIeqkvktCj6YMGAaGpnQkPgVJcT2HeVMs+IEfX5+5Bl9EnkKI0MNWfx8YzvpIlYZcKtCgdEFU4uoYxi7NXUHdBrhUp+KnRU93s5ifzMr0rgGqjsZDHmn8XbyH1hscrvYCLcTzQU2W41k 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 Fri, May 09, 2025 at 12:24:56AM +0800, David Wang wrote: > At 2025-05-08 21:33:50, "Kent Overstreet" wrote: > >The first question is - does it matter? If the optimization is just for > >/proc/allocinfo, who's reading it at a high enough rate that we care? > > > >If it's only being used interactively, it doesn't matter. If it's being > >read at a high rate by some sort of profiling program, we'd want to skip > >the text interface entirely and add an ioctl to read the data out in a > >binary format. > ...^_^, Actually, I have been running tools parsing /proc/allocinfo every 5 seconds > ,and feeding data to a prometheus server for a quite long while... > 5 seconds seems not that frequent, but I also have all other proc files to read, > I would like optimization for all the proc files...... > > Ioctl or other binary interfaces are indeed more efficient, but most are > not well documented, while most proc files are self-documented. If proc files > are efficient enough, I think I would stay with proc files even with a binary > interface alternate tens of fold faster. This would be a perfect place for a binary interface, you just want to return an array of struct allocated_by_ip { u64 ip; u64 bytes; }; Printing it in text form requires symbol table lookup, what you're optimizing is noise compared to that and vsnprintf().