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 B57E8C47422 for ; Sun, 21 Jan 2024 23:40:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F2E16B0074; Sun, 21 Jan 2024 18:40:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A28C6B0075; Sun, 21 Jan 2024 18:40:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 26A358D0002; Sun, 21 Jan 2024 18:40:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 18B3C6B0074 for ; Sun, 21 Jan 2024 18:40:06 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BB64516022C for ; Sun, 21 Jan 2024 23:40:05 +0000 (UTC) X-FDA: 81704938770.18.741FC53 Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) by imf17.hostedemail.com (Postfix) with ESMTP id 07BEC40006 for ; Sun, 21 Jan 2024 23:40:03 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=mCZc1eIP; spf=pass (imf17.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.175 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705880404; 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=SZc1NI/EZk1iJ8ESuXFylUUNLhNjkoITNYsKTA65vog=; b=BEQJetKy665Nez3NxNPTLy/FMFAzcf3OUUCFq9Svs5dx0CgrZEE68Q+bmBkcueuzxxVWNR 5nzjQq3uIlN8AiDsfpRAH+IsWcuCRuCfRHFSpBjbiyXuWRJ4bDfRfQKKjzLDD1RrEqNVhB 4laI0i0ePU5Pt5X/raVZ23y97O/z9pg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705880404; a=rsa-sha256; cv=none; b=j0vDQMIgSrFE1R0Ac/9HsL7DcjJfEjlnNZBtDg2GttnOiTBwjQyZbNLWGIYzdWtyYz2sxW WSUh6q0d9C3vJKgVJqu8ocbXp2szBaItfYWE3g8RCBeg1eRHEdOOh+mHRgTNIs6UWT6np/ TabgAztBrW9LjT+wRsrhoETreo9EWzY= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=soleen.com header.s=google header.b=mCZc1eIP; spf=pass (imf17.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.222.175 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=none Received: by mail-qk1-f175.google.com with SMTP id af79cd13be357-783293278adso239612085a.3 for ; Sun, 21 Jan 2024 15:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen.com; s=google; t=1705880403; x=1706485203; 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=SZc1NI/EZk1iJ8ESuXFylUUNLhNjkoITNYsKTA65vog=; b=mCZc1eIPZ2Apsz45mrl/wvdHG1psq25Lg+oYU2oD6opPWl9C5YKOY36rAVGFt8p0VE OnZT/+RbkNgqyZPeHb6D8Ddq2xA8hZImz1iQDTFvVM9HSp72ms8A0wNU1sAd1SWVVPz8 bjQoJaDkU9EbS9RKYZdNvGAlGtlQO39PrVLp0ryl1k/m7O64C5APDxKZkRTXQwfpRU9i 8AW4Ihpbhp5FuSMgV7pXaRuSFaccu7jeXW+ruBMByUu4NkJrynxEd/pvm1e5EyxD0prK TSDvjSmiNPaK3cGzLgJ29zLJgECdxJRkDwebIIW6A7dChkEJZQGKGIelM4RZDyf6RceA KukA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705880403; x=1706485203; 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=SZc1NI/EZk1iJ8ESuXFylUUNLhNjkoITNYsKTA65vog=; b=E+W4tEbPSAkyozP0IdZ5WW3ZWtthdnMPQ1LpMjt9wspIwDH23BXUEwmhxtZkOaODZK LMM/SzrpV28cOU/NtPiZ4PEAHsRoEeoNgs1gaEJnABnjdzk6juadVu6q8UG9miDv8Nt5 Xq4bzJG0g8Jhut4g6l0s/T3zErfs2uw1rBuByY1fir3777uaM4FSkXK3cv+jkDTPOBZZ m+OEFks2CuoGAZHJBhZA1rA5DNSHz0rGheqacaDD+TlbaUbyUEkG7xI/a7om/V0U/sHK cTMv0bydaNtwebVwe5PcCXyGJ9i3/JcHdo7uFA9z1OLL44KcGh91ZeTPZU46vQhIUVmE lW7g== X-Gm-Message-State: AOJu0YxZpKlBfrFCIDRUz+3l1Z/tYZYKamLYUUf7J0lq+K1igsV1FP/6 op8W8l54o+s7s2cGSPVfU5cNLAjZh4/Aw+qw2SxTz0vDnOyL1aDb7HvwlUuwowSXsuNbpmVJp9/ WOR5JNtkp7YWAsONCjmkg5EBErL/kLpdE8YsbUg== X-Google-Smtp-Source: AGHT+IH5ycIqMi3jDrjLoeYUHtQzDyjfbrB05D64wCkwHBvitYAAjRqtVj46x2LsSIh2GQ8dvjslhXTJ0TJhNa/4OaY= X-Received: by 2002:a05:620a:28d3:b0:783:9899:a165 with SMTP id l19-20020a05620a28d300b007839899a165mr3085566qkp.31.1705880402961; Sun, 21 Jan 2024 15:40:02 -0800 (PST) MIME-Version: 1.0 References: <115288f8-bd28-f01f-dd91-63015dcc635d@suse.cz> In-Reply-To: From: Pasha Tatashin Date: Sun, 21 Jan 2024 18:39:26 -0500 Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Memory profiling using code tagging To: Kent Overstreet Cc: Vlastimil Babka , Suren Baghdasaryan , lsf-pc@lists.linux-foundation.org, linux-fsdevel , linux-mm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: y1i3dizwe8rf9j9arx1tmctnxi4o1bk6 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 07BEC40006 X-Rspam-User: X-HE-Tag: 1705880403-190164 X-HE-Meta: U2FsdGVkX18EfVnhOE3d7t9fkTfv6oEJ+C5AotY2g9XWPPOd2NJBSTHoLNif3gUk5c4q5yOIpHR0j6jzl0OkwgygPf9kaUnsgOkjok/dMynyPizEtoQ7by/tcdYv7duvp/IUVrh5i3WdFm748FTvUjk3R9qgG8nYXm9XSw+j4HrOs2YIPUy25S3fZ32iK+nMm2/prOj82qFkaLJ2sP50f/Ex++7S4m+eni6GOBvYkZwo8m9CKwJLNelE1da8L9WJ3PRc6b9vPFS1vQXGlj22JnfqNaLb96U9hfGDBGJzP+YBRZjLeHOVfSMm/GY07m+aeSETNcIBpb0+QPi/pgz42/Y6s4jf6mjGoo+d6zQNrTBgRecvfZOGSPR/L/U8uIyoxooBlC1anZ3Yj4dwWJ1Yd1+pW/hWfeukTRkxOWY3Ws5PWD2vUvrjUErELAiNUBmXv5BuDOOBpoIra09Mi4xgyi78OU0je2wovBNkTY9X18iq/x+yjYRDcTrnA5zJWtR/fYQGIiM67H1FQgD7+zLzUuLZee+bTzJUvA5txseHTaVephg4RZKMtag1BkmKQjSTpBRsd9VdOVmwherUv9MF9+INyyIwFVCmMrDeVqDn1DrfbsQ7Giv1gGV5JBUNuxEHIg3r+6o07jLF76aMDLl3F4FXVvM8LZe+rCGt/mNgwEPdba5untCXuJzdgm9a2SwzTYklX3VH2+yHwbQZjRbC/+/WcRnWsd/9v3jaJgIl3J0gt+KEEzWJsJTFpu7NDUdnhC+M8EzlAhE8oGhHlLnR+D5UqO8xBBbZVkifN7WOba1nDF0WbT3URP4+7/n3oyI0wlXOsi+fLWdeO0NGaO8lSSAZaFbk6YegEP01y830aKx7FDJMtOZwkFpuigHC1OpjbRKDBDgVdAINhfuSFhmhi2TLSy1Ee3GzZ7yVgpelXsCONtXFEHK/wFEI4wpZjGnX894/CJCeUFOrjZyT066 x3uCXIST R2Q32Rxlvm+Fg66YkDSWHxuhbUd3fpf444xHeGA84s4/kSOGkMrfFqZ8k8JwkEWXAnxqzJNzUYq8r9qLhl/JZEyMPO9lcHRA4aKA5NvF2M5F56S1UsX7mrGKXGMRaoCgBDPC4d1oOPKjB421IoUhXEXMx3f50SvHbMwiSF1ETU9Ru+xFLQU0+iiZZEsih25ERF/CQdvbz/91+fws= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000508, 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 10, 2023 at 12:28=E2=80=AFPM Kent Overstreet wrote: > > On Tue, Mar 28, 2023 at 06:28:21PM +0200, Vlastimil Babka wrote: > > On 2/22/23 20:31, Suren Baghdasaryan wrote: > > > We would like to continue the discussion about code tagging use for > > > memory allocation profiling. The code tagging framework [1] and its > > > applications were posted as an RFC [2] and discussed at LPC 2022. It > > > has many applications proposed in the RFC but we would like to focus > > > on its application for memory profiling. It can be used as a > > > low-overhead solution to track memory leaks, rank memory consumers by > > > the amount of memory they use, identify memory allocation hot paths > > > and possible other use cases. > > > Kent Overstreet and I worked on simplifying the solution, minimizing > > > the overhead and implementing features requested during RFC review. > > > > IIRC one large objection was the use of page_ext, I don't recall if you > > found another solution to that? > > Hasn't been addressed yet, but we were just talking about moving the > codetag pointer from page_ext to page last night for memory overhead > reasons. > > The disadvantage then is that the memory overhead doesn't go down if you > disable memory allocation profiling at boot time... > > But perhaps the performance overhead is low enough now that this is not > something we expect to be doing as much? > > Choices, choices... I would like to participate in this discussion, specifically to discuss how to make this profiling applicable at the scale environment. Where we have many machines in the fleet, but the memory and performance overheads must be much smaller compared to what is currently proposed. There are several ideas that we can discuss: 1. Filtering files that are going to be tagged at the build time. For example, If a specific driver does not need to be tagged it can be filtered out during build time. 2. Reducing the memory overhead by not using page_ext pointer, but instead use n-bits in the page->flags. The number of buckets is actually not that large, there is no need to keep 8-byte pointer in page_ext, it could be an idx in an array of a specific size. There could be buckets that contain several stacks. 3. Using static branches for performance optimizations, especially for the cases when profiling is disabled. 4. Optionally enable only a specific allocator profiling: kmalloc/pgalloc/vmalloc/pcp etc. Pasha