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 97217C48260 for ; Fri, 16 Feb 2024 09:02:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 293218D0010; Fri, 16 Feb 2024 04:02:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 242D98D0001; Fri, 16 Feb 2024 04:02:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0E3178D0010; Fri, 16 Feb 2024 04:02:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F275C8D0001 for ; Fri, 16 Feb 2024 04:02:39 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C4F061A0376 for ; Fri, 16 Feb 2024 09:02:39 +0000 (UTC) X-FDA: 81797076438.18.61BC9DE Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by imf26.hostedemail.com (Postfix) with ESMTP id E77FA140020 for ; Fri, 16 Feb 2024 09:02:37 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=o9R6EhdE; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.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=1708074157; 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=aC0zV0jURwgzq9Q6615BgsaS7tbK8PR71BWfZKB9Bg0=; b=VbKaKTWv5h3/sIG3xZ/dflsvjaUvRFpe8MRJZMSjPxBk372xIEu0m4UuXKe83Z+kNZaVoN zxiPnWcDJajq83AVyazY8vX1NNEw0kPo8iWGPCXwXEPXk+wsl9a18moz0yanGAeIR7p1Px u/bGbi2Tw2gdxEo4gXvpbVIq48yNbJA= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=o9R6EhdE; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708074158; a=rsa-sha256; cv=none; b=OOBJGG9qVqHk0ftLAWV1TXCGwTG/ukNSnrEoN2chk0d5bDUNikVSg/x48fYwfDzjJ+NCqu 6m3nUA75GpyKu7LSlsR4komoY8u15gva35QuQoYwPoBY0fhij4ROQ66XYXd+4BmGohsfIK oqWpouo1/5K9kGLH2v5gmfyQRY2nqM8= Received: by mail-yb1-f174.google.com with SMTP id 3f1490d57ef6-dccb1421bdeso1718381276.1 for ; Fri, 16 Feb 2024 01:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708074157; x=1708678957; 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=aC0zV0jURwgzq9Q6615BgsaS7tbK8PR71BWfZKB9Bg0=; b=o9R6EhdE87OvmR+Y4M+sWO6+43xDgNxMkQ+oIMcn5XJm1ZvDcBqQIwfkFeyXMAPkHo +4zFsiapeJPjMNl3KqhdugBOLbaOv7/LdZgTchZ0qKD4lO9XzDdMmFsrfJrIhV+P4XBH Q/6Lh2+v1g+TMPVsFsYJWeIL2dNU41aYh5ByGfaY+gEzVLwVSDuKRNC+6S7qHUxld3xs 1a+yv9sGu/Ddk5pro88KbUV1p7tSXUjRXxHLg8HCjRyDDEmbzb5YmL/K4fG74m7CuvRj w3FeAnEO6Atht9g4BjYYKnui+fG8bOcABPWR7K/4389oIn1LW/ifPqtphzd15IrsLiBa 6uig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708074157; x=1708678957; 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=aC0zV0jURwgzq9Q6615BgsaS7tbK8PR71BWfZKB9Bg0=; b=cpw8OR8qF2hTY5pcih3BJT+40ndijlTHxXe90I9oKRzNHIUQM0DW2a2CbnOvNY2JoB Np+TmvuNE2rvgef6urwxVG+Vgmnnex01Bj/jKMSK4G4PtG62eAbW1dWX+3hyvq0o4x7+ y7WHhS7X2oi26wWdQ+sRI5NkeU/pOUQPmI/YJNjMsRlnGN+7rUasFhu+V/IUn8vPFm+G XzyvckX/nnig+E8s4qNT8CzkPOYD77hWZIA5HjLZmGBdJ/SBHFhqMgCQPmCrpDQkmugl JomDFbb2Jkv5PwDEokIobJb2Xy5MYJ2YXCiMdTwqpX3EWTPU44h/vBCQcrf+I9wUWbRH gFqA== X-Forwarded-Encrypted: i=1; AJvYcCWWAAknMyQX6gpgTID510dILbuwBFhQg+OtXeln4hlNC8CA9+Reb5+gSa0BrFXFrozdemFChnzjgrvL/yayuDgt1Qg= X-Gm-Message-State: AOJu0Yw5cse0nOq4Sz+jg04DdX5jEqeEl6uxou2Ce5z6kkLiOf/DUWSx cOdRRUpLmkJgB+jg8NeKyva0DClb/DgliJA++dEoKMzQgmRXnsODz0Dsfj0zfxTD+iMddrY9MX8 6qsdaTauck9ViRF7sqFxRsMnbkQZgt8sv1GLZ X-Google-Smtp-Source: AGHT+IEM+380cGg5HHP1OkOXBhTo7zHOdUbLmTZ9RIz7nJiHcIKUi7+k7jSA3j73/vSCaixotNnzkCuz3vuGoeIcxZc= X-Received: by 2002:a05:6902:1b85:b0:dc6:421a:3024 with SMTP id ei5-20020a0569021b8500b00dc6421a3024mr5156888ybb.43.1708074156727; Fri, 16 Feb 2024 01:02:36 -0800 (PST) MIME-Version: 1.0 References: <20240212213922.783301-1-surenb@google.com> <20240212213922.783301-14-surenb@google.com> <20240215165438.cd4f849b291c9689a19ba505@linux-foundation.org> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 16 Feb 2024 01:02:25 -0800 Message-ID: Subject: Re: [PATCH v3 13/35] lib: add allocation tagging support for memory allocation profiling To: Kent Overstreet Cc: Pasha Tatashin , Andrew Morton , mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, vvvvvv@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: E77FA140020 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: tn6s76dh6n4yp4byz4aiqsu87h7zcebi X-HE-Tag: 1708074157-885904 X-HE-Meta: U2FsdGVkX1/sdPg9FynCPNATztAiSFiJO7+cOyN+WjUJ/dNKKLkdfdvjD9LQN0Ad4bPPEyzVOynaB3ib61a8CG9TJelxMWw7FnydnrXXYN3uBo0fmqX5bXgXojXykmYzR/9bfcRYM3NW8jQxB/5Mf8MkTNcVI2rrucDvhjWvBlovOZVGnLBvwBJ98h6/CGwWrdOX0TQyf/vZ+ddMXPtyLYfiFJ/iuw2plsZ5fU7LhubaZgVo5jPXMfgRhuyC4xCAIFfI0n2hvLJQGOsk7Bjp4OMTyNuMIX92I4Xip9TRLt/Vw2axjuxVxyoy+FVf4PQBXmhT4JERuOFhD3bywmPKLyOoym9VZtTBFsrDx+TylVHwoNtW30jdevVMeo0PJubnQjEgeSZtFPScX8+Q6A/VZgebls+tGC5/S2Wt4wEIGXSirIP+NaxeSkNvti6fy77qaGon9xxhEDOH0qE+TjX0uUnq2YRorikArwC+KD2rTTbs7vhS+P9Y0UK0wOYivTiYn8t16zT6WV02emO6V/6LfY0NONBXn/Hr78tdOFgpRaCzBJZuyNYToD70BCoQ1gWOZM2piJS8cFOsoEFe5vBO+dXF+ANv/ge3wKIg1g9nZ58UPC1caDS6+45z//GLHElLOY9pRu8V1y9ssJcQaulnPyff3iq19ql0wkMpYmAw4dRdHzDIs+nnIFTv+Sw5OmO6wGGEDqwdPonew+ExmgQUA16+3LMFLUSlYDICN+pEcU0/GSIzuh/IL6mwOd0lLYtdDz4UT3W3FcGJQdPz9CaBi7rz/clY2ByNOxXyp7jCGSSEUFObwx5bBp7FMaSW1UJTQCJQ0wNob1pPx8Vfwiq1oM/wOyBWk35pbghjgJm5OoS4Yl9EbOJRK4CagLJ933L4zUY7IfnNWfu9W0xzAIH1c3yOZW8fFDzJ1wd70K3Gipp6Dz0ibBSEPIAZQHU6i/tLixdql+3iFjUEaZc19pz 0xTdpb70 gtnEoarPi/5RZ2HdOiAX0iEsac2Z9E2aPJNp95iP8FZ2242VwwijwcDoq2lNFzE5qctvjXnyfJQdelXvPXgfj3FRTZGUgtDFptxrzMO4YaPpojrZ+c2xTuKbh1r2u63FguDzHO4XWAXY0b6dlyvd7YiLBmiJHVNtt2gfsR0XG1TGR12mHYXwqLoXSCeJy4K2hplD7DoBK2ASZ0FmAe1npHrgztM8U6J4cflm9wYA/52jWuf1BrWe+KbQgMvT8ZfP4TPxONPE7b2leEWC3OykRS/dZ7Pgu2TmDv/lQmtd4DMtXQrUcdUHnd+TCGAysldbeCTl9 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 Thu, Feb 15, 2024 at 5:27=E2=80=AFPM Kent Overstreet wrote: > > On Thu, Feb 15, 2024 at 08:22:44PM -0500, Pasha Tatashin wrote: > > On Thu, Feb 15, 2024 at 8:00=E2=80=AFPM Kent Overstreet > > wrote: > > > > > > On Thu, Feb 15, 2024 at 04:54:38PM -0800, Andrew Morton wrote: > > > > On Mon, 12 Feb 2024 13:38:59 -0800 Suren Baghdasaryan wrote: > > > > > > > > > +Example output. > > > > > + > > > > > +:: > > > > > + > > > > > + > cat /proc/allocinfo > > > > > + > > > > > + 153MiB mm/slub.c:1826 module:slub func:alloc_slab_page > > > > > + 6.08MiB mm/slab_common.c:950 module:slab_common func:_k= malloc_order > > > > > + 5.09MiB mm/memcontrol.c:2814 module:memcontrol func:all= oc_slab_obj_exts > > > > > + 4.54MiB mm/page_alloc.c:5777 module:page_alloc func:all= oc_pages_exact > > > > > + 1.32MiB include/asm-generic/pgalloc.h:63 module:pgtable= func:__pte_alloc_one > > > > > > > > I don't really like the fancy MiB stuff. Wouldn't it be better to = just > > > > present the amount of memory in plain old bytes, so people can use = sort > > > > -n on it? > > > > > > They can use sort -h on it; the string_get_size() patch was specifica= lly > > > so that we could make the output compatible with sort -h > > > > > > > And it's easier to tell big-from-small at a glance because > > > > big has more digits. > > > > > > > > Also, the first thing any sort of downstream processing of this dat= a is > > > > going to have to do is to convert the fancified output back into > > > > plain-old-bytes. So why not just emit plain-old-bytes? > > > > > > > > If someone wants the fancy output (and nobody does) then that can b= e > > > > done in userspace. > > > > > > I like simpler, more discoverable tools; e.g. we've got a bunch of > > > interesting stuff in scripts/ but it doesn't get used nearly as much = - > > > not as accessible as cat'ing a file, definitely not going to be > > > installed by default. > > > > I also prefer plain bytes instead of MiB. A driver developer that > > wants to verify up-to the byte allocations for a new data structure > > that they added is going to be disappointed by the rounded MiB > > numbers. > > That's a fair point. > > > The data contained in this file is not consumable without at least > > "sort -h -r", so why not just output bytes instead? > > > > There is /proc/slabinfo and there is a slabtop tool. > > For raw /proc/allocinfo we can create an alloctop tool that would > > parse, sort and show data in human readable format based on various > > criteria. > > > > We should also add at the top of this file "allocinfo - version: 1.0", > > to allow future extensions (i.e. column for proc name). > > How would we feel about exposing two different versions in /proc? It > should be a pretty minimal addition to .text. > > Personally, I hate trying to count long strings digits by eyeball... Maybe something like this work for everyone then?: 160432128 (153MiB) mm/slub.c:1826 module:slub func:alloc_slab_page