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 E8D75C54E49 for ; Thu, 7 Mar 2024 16:51:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5512C6B0204; Thu, 7 Mar 2024 11:51:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D9E26B0205; Thu, 7 Mar 2024 11:51:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 354596B0206; Thu, 7 Mar 2024 11:51:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2036A6B0204 for ; Thu, 7 Mar 2024 11:51:25 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AC5CA1A0CA9 for ; Thu, 7 Mar 2024 16:51:24 +0000 (UTC) X-FDA: 81870833688.28.FF8B2B9 Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf04.hostedemail.com (Postfix) with ESMTP id 057F240027 for ; Thu, 7 Mar 2024 16:51:21 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fhCqq6Gh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 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=1709830282; 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=+Yc7CaZYI+aOfiJp3dG8X2zo4+LoYMopU2pW1vALF2c=; b=NparFWo6gcJrh+aCGY1DRUyW8krdmVEwCaYCEfPJMNsiEe4JqyvJYhvGAgmLzZ1DKr0k0c YDEP16NpIWx5Rnd0WI1zntGIvzgyZEXy8SW63E0OkUVRPCRQOMBA6FNXDukkFnGJzmCvtu 80mbIoicVJps17L2YqhahgbKLPobmos= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=fhCqq6Gh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709830282; a=rsa-sha256; cv=none; b=XsXfnTS14QmCNTFcrt7bpZqRh0bxI3C2FZCX6Vx+C+u5DBenANpxaZviCQzREQkwIPsLH9 zHIE+Ooz9D/Rqh8FL5p/VSatcNMI4bR5B8n42NjaP9DGqKfgFLccv8X+pGOfMXzi5N9jwu D7+zWzV3funrB+BKRRpQ9RauEYPwnbI= Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-607c5679842so11531567b3.2 for ; Thu, 07 Mar 2024 08:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709830281; x=1710435081; 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=+Yc7CaZYI+aOfiJp3dG8X2zo4+LoYMopU2pW1vALF2c=; b=fhCqq6GhDyUrvLdwp476YTvYhtu6iDL26GWfFwnLJIn3HVw42hPSDg+ktUzX3drA1W laecf/xs8RZdrIbqUU9jaO1NLFbINcjiKNOaTRytd5KseUKBD2AdL7rkhP/fCcZPgfFi SQqi3Ecy2EuzbLdyB9mvGkknzODt6NgOKOlcoSXZ5khjljsJ8p1SWU3hBv7a1FVLD1a8 eEui18gJACH6tv6HCHqIq6/4ApaPKKaFeyYX+ibX38tPVnb5Fd6khacwm7bUkZhft5y0 IeUDSWZ6Hh1nFBvLOQ/Hk32A8OwshpS6XbZUXEYC1Is7YIwckUuUJ34Ew5c7rmzERIbj 6D+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709830281; x=1710435081; 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=+Yc7CaZYI+aOfiJp3dG8X2zo4+LoYMopU2pW1vALF2c=; b=kkFZ/FmZPXHzTOg4eTaoci6SExGSpcOLLLn4YQ0/atGFgIdUF9tbe/2jdWFJw4/sAW e/kJO5cKhMkeK3kHk/tna0+xs5t16bGiy+JtcJOtpI6XM9qxa0OfGSJsaxXRtaG5Tje3 zanyNBreZMYXNHZTDbiPsyRLh5PeF0XqOAHZPY3kIiF7o9UZd8pnnKR1g0LdxDeVEthE Aaz6kqKD6u5qZUJquV7bvERyGKOuHDcfYh8MzM4uX/+HfUW7/1qJgaC4TBrNPMJ1BPm+ DMC2BOT0qAeZ0FStKH2Jn7yJe3GlIZbaJgit13aW8JFaB5oHir4IMZv44UyYeIBLgPMU KhVA== X-Forwarded-Encrypted: i=1; AJvYcCVul4bCriq7OSKlMl6U3EfhVPTcfk/VcZjqwPp9TDrQqvUSoSijB34gLS/QpjcDzQhDVyu2SR3QzbNhHi5GdkyEQ10= X-Gm-Message-State: AOJu0Yxm0z+tU/I9M3Hgf8Et05H7XBrEcaCHQJkVqmsB/BDRMKnjoAfO KTnLVvWM7HRgZ0uOqGpbMaHojAvj76uP/AuEX6HclTCsXzhNVUkSrKWRG9bpFKLiSOJNKnhNAHx ckXsy5qm/6tIip+L3IhPGjKv/ihRzJX7zGnUw X-Google-Smtp-Source: AGHT+IETO+uYsXBHUav01bdbNnbA53xxjR6usX/j/Y4xXR7KlOH6v3HVx5uc93IkxR9q2hK67467LC5KnM+ZNqEyIOk= X-Received: by 2002:a05:6902:160d:b0:dcf:56c3:336e with SMTP id bw13-20020a056902160d00b00dcf56c3336emr17705298ybb.35.1709830280572; Thu, 07 Mar 2024 08:51:20 -0800 (PST) MIME-Version: 1.0 References: <20240306182440.2003814-1-surenb@google.com> <20240306182440.2003814-38-surenb@google.com> <10a95079-86e4-41bf-8e82-e387936c437d@infradead.org> In-Reply-To: <10a95079-86e4-41bf-8e82-e387936c437d@infradead.org> From: Suren Baghdasaryan Date: Thu, 7 Mar 2024 16:51:08 +0000 Message-ID: Subject: Re: [PATCH v5 37/37] memprofiling: Documentation To: Randy Dunlap Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, 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, penguin-kernel@i-love.sakura.ne.jp, 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, jhubbard@nvidia.com, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, 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, aliceryhl@google.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: 057F240027 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 3hhadaxijmpr3ugnaz14g9dhjohzgm9n X-HE-Tag: 1709830281-363452 X-HE-Meta: U2FsdGVkX1/MwPmdRZxzMsAZ074OiHh+OVxzNlGuG56KY1hbRm1D/mmyC9g0MeqI0f2UYrMpLp05I3UfQqlkUZhDBX7TZT+gDHNRPI0hF195J9FEFnwePgT5submuXrdl9fJsm/mIwfsqmL9IUn+qtlJibj/alATfkG/nwwndnDtHGbt1f78cPoJIMtEpb/3cBgkNbAPOahV2L4m57AiPlHUybDXQXAPbMVEkgFj6tmogId3QzhCuLoiHQ4RHW/frl2BfICFbvsFWkXqNsmdpXUsTpLNMUXxLEgvn0JbcfSrLzG7C3XFqV76eV4avVccXzu8H0pMzu3yuukhuT/S7evZX06ZPihusVG89uR6hkP5mhKq/zz1EM8r1j4Z8q4uJX9kMDYsps09Lr39yD3n26S85YxfNhQKdn/37S56fi0N885WAPHymvcTw1pZWsjreTIRY4+y1oP6+9yJdG3k7Nu03kpFnGYtKuaSuZd6QPE+ot5FlP8jWx1QWZ8LnRyj8X5qBvAuQ/wcBq/G0ZxS6XVGNrPfmEZJ18jm0yvz1YpNKlWqizhVQzPL0rYPcHk2bNhMU4g5LTEd0ZdSU33aeWd1xBAo7MQ7EYQjG1pPGVintAvqFsDcpRsp3Ff+50idtVly5EyPeSGfAvLsudzxDxEeoUdRMQA1Hf/K87evhlGTP3E3dN2iqdB2URyB1lxHf0Jn8Ga4X8345F+c9QbZkjtCUFISrtkEt5HWys8tKA7H7Dyeuz2mV/p/mUwVQ+qdaWlgnIifSaTnECNsZuFazamK5SgQrBKeHxxJ84eI+liYPTGNk6gx+a6/jVW9rhYBwhOrDhmShvavA+nRek6/B5FVweGA35pujeaCeyP/l+wpXcCFY9zf4CIY3iyVNB15WwkGSCDMODCoC/yLgOYOpMn2ShuOoqFLzF/k4IW5Y+W67euEM3YokTeVGL9gdBoOy8FKbQitJ7Fkr63TsbG jUrKv4gz CymGiQtyvqwHjts1SDgC+BmZVnFM+jWDdH+KBF68csozrB8pb2Rxjmja+0gP75jlrDQ6w 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, Mar 7, 2024 at 3:19=E2=80=AFAM Randy Dunlap = wrote: > > Hi, > This includes some editing suggestions and some doc build fixes. > > > On 3/6/24 10:24, Suren Baghdasaryan wrote: > > From: Kent Overstreet > > > > Provide documentation for memory allocation profiling. > > > > Signed-off-by: Kent Overstreet > > Signed-off-by: Suren Baghdasaryan > > --- > > Documentation/mm/allocation-profiling.rst | 91 +++++++++++++++++++++++ > > 1 file changed, 91 insertions(+) > > create mode 100644 Documentation/mm/allocation-profiling.rst > > > > diff --git a/Documentation/mm/allocation-profiling.rst b/Documentation/= mm/allocation-profiling.rst > > new file mode 100644 > > index 000000000000..8a862c7d3aab > > --- /dev/null > > +++ b/Documentation/mm/allocation-profiling.rst > > @@ -0,0 +1,91 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > +MEMORY ALLOCATION PROFILING > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > + > > +Low overhead (suitable for production) accounting of all memory alloca= tions, > > +tracked by file and line number. > > + > > +Usage: > > +kconfig options: > > + - CONFIG_MEM_ALLOC_PROFILING > > + - CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT > > + - CONFIG_MEM_ALLOC_PROFILING_DEBUG > > + adds warnings for allocations that weren't accounted because of a > > + missing annotation > > + > > +Boot parameter: > > + sysctl.vm.mem_profiling=3D0|1|never > > + > > + When set to "never", memory allocation profiling overheads is minimi= zed and it > > overhead is > > > + cannot be enabled at runtime (sysctl becomes read-only). > > + When CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=3Dy, default valu= e is "1". > > + When CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=3Dn, default valu= e is "never". > > + > > +sysctl: > > + /proc/sys/vm/mem_profiling > > + > > +Runtime info: > > + /proc/allocinfo > > + > > +Example output: > > + root@moria-kvm:~# sort -g /proc/allocinfo|tail|numfmt --to=3Diec > > + 2.8M 22648 fs/kernfs/dir.c:615 func:__kernfs_new_node > > + 3.8M 953 mm/memory.c:4214 func:alloc_anon_folio > > + 4.0M 1010 drivers/staging/ctagmod/ctagmod.c:20 [ctagmod] f= unc:ctagmod_start > > + 4.1M 4 net/netfilter/nf_conntrack_core.c:2567 func:nf_c= t_alloc_hashtable > > + 6.0M 1532 mm/filemap.c:1919 func:__filemap_get_folio > > + 8.8M 2785 kernel/fork.c:307 func:alloc_thread_stack_node > > + 13M 234 block/blk-mq.c:3421 func:blk_mq_alloc_rqs > > + 14M 3520 mm/mm_init.c:2530 func:alloc_large_system_hash > > + 15M 3656 mm/readahead.c:247 func:page_cache_ra_unbounded > > + 55M 4887 mm/slub.c:2259 func:alloc_slab_page > > + 122M 31168 mm/page_ext.c:270 func:alloc_page_ext > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > +Theory of operation > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > + > > +Memory allocation profiling builds off of code tagging, which is a lib= rary for > > +declaring static structs (that typcially describe a file and line numb= er in > > typically > > > +some way, hence code tagging) and then finding and operating on them a= t runtime > > a= t runtime, > > > +- i.e. iterating over them to print them in debugfs/procfs. > > i.e., iterating > > > + > > +To add accounting for an allocation call, we replace it with a macro > > +invocation, alloc_hooks(), that > > + - declares a code tag > > + - stashes a pointer to it in task_struct > > + - calls the real allocation function > > + - and finally, restores the task_struct alloc tag pointer to its prev= ious value. > > + > > +This allows for alloc_hooks() calls to be nested, with the most recent= one > > +taking effect. This is important for allocations internal to the mm/ c= ode that > > +do not properly belong to the outer allocation context and should be c= ounted > > +separately: for example, slab object extension vectors, or when the sl= ab > > +allocates pages from the page allocator. > > + > > +Thus, proper usage requires determining which function in an allocatio= n call > > +stack should be tagged. There are many helper functions that essential= ly wrap > > +e.g. kmalloc() and do a little more work, then are called in multiple = places; > > +we'll generally want the accounting to happen in the callers of these = helpers, > > +not in the helpers themselves. > > + > > +To fix up a given helper, for example foo(), do the following: > > + - switch its allocation call to the _noprof() version, e.g. kmalloc_n= oprof() > > + - rename it to foo_noprof() > > + - define a macro version of foo() like so: > > + #define foo(...) alloc_hooks(foo_noprof(__VA_ARGS__)) > > + > > +It's also possible to stash a pointer to an alloc tag in your own data= structures. > > + > > +Do this when you're implementing a generic data structure that does al= locations > > +"on behalf of" some other code - for example, the rhashtable code. Thi= s way, > > +instead of seeing a large line in /proc/allocinfo for rhashtable.c, we= can > > +break it out by rhashtable type. > > + > > +To do so: > > + - Hook your data structure's init function, like any other allocation= function > > maybe end the line above with a '.' like the following line. > > > + - Within your init function, use the convenience macro alloc_tag_reco= rd() to > > + record alloc tag in your data structure. > > + - Then, use the following form for your allocations: > > + alloc_hooks_tag(ht->your_saved_tag, kmalloc_noprof(...)) > > > Finally, there are a number of documentation build warnings in this patch= . > I'm no ReST expert, but the attached patch fixes them for me. Thanks Randy! I'll use your cleaned-up patch in the next submission. Cheers, Suren. > > -- > #Randy