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 14FA9C7618E for ; Fri, 21 Apr 2023 11:20:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BD346B0071; Fri, 21 Apr 2023 07:20:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 16E006B0072; Fri, 21 Apr 2023 07:20:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 034A96B0074; Fri, 21 Apr 2023 07:20:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E87A56B0071 for ; Fri, 21 Apr 2023 07:20:21 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id AF705A06FD for ; Fri, 21 Apr 2023 11:20:21 +0000 (UTC) X-FDA: 80705154642.22.B65F37C Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) by imf30.hostedemail.com (Postfix) with ESMTP id E6D5A8000C for ; Fri, 21 Apr 2023 11:20:19 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=ZwRBjRJ+; spf=pass (imf30.hostedemail.com: domain of glider@google.com designates 209.85.222.45 as permitted sender) smtp.mailfrom=glider@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=1682076019; 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=H+bvG24rbj6Mwo1aSiBvly3dKujd5OE0y4T3IN5Gcis=; b=D8bMKvlYqRq98ziAuLIEYrYrjs7qxEMCEHNBZh1WKa195kUzNy1SGs62m/LyBCberjkEgj tqEGJteNiolfjzl71/o8OESjWRPa6xzgcC5fpEcEQ3jWvaoZoK6ILdWaR8MBXWTGVvGyFB BKr9BQknkLslNL0raGXq5fwvkW3YoAY= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=ZwRBjRJ+; spf=pass (imf30.hostedemail.com: domain of glider@google.com designates 209.85.222.45 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682076019; a=rsa-sha256; cv=none; b=BR3blCHlVNF9VTNBi1oL9Ts2n2c28P8k7x/4Pi0YcAV2Y0RRWlDQrk99s7cATzonkDmv7Y WPNnv8CTU6ASuleIK4zFnmCF5+ElVYpJ1LccHrpmt68HuYrJC/4ITW/0MszKsfMIIcKGcv 9ElH2EevVzFTBYNyyh8CqhGvirCIe2I= Received: by mail-ua1-f45.google.com with SMTP id a1e0cc1a2514c-77858d8dcb5so6387933241.1 for ; Fri, 21 Apr 2023 04:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1682076019; x=1684668019; 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=H+bvG24rbj6Mwo1aSiBvly3dKujd5OE0y4T3IN5Gcis=; b=ZwRBjRJ+anhiesy73RmJ21BZRFAPms930ivmq7t1dyYs9JjJgoqwAWlAU9JJTYTwLN i8CV8K1NV/1NHgAp8qNRPLt2ZYT8yi1+BygITDu/qi/Umh+fRiRCfnaAx496T3pVr2+g E+caliM9mIBhekcjkGaEwdNPVfQr7uMDRzQwz/NPmq+8Xk24oW8SyRgSrdZvMgARgXPL YnLbRcg2DZImn5sX921X/aSrxVYikiUQ8XoBwo3xr3ImaG75JWQ7Y1X0T13R38KjA8Tn sddOZUCP466Ndwu73JRcLHUSS9xDxowUo24EFajBdNjecoRB4ilSF9PIP6G9B/MxAizq 37tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682076019; x=1684668019; 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=H+bvG24rbj6Mwo1aSiBvly3dKujd5OE0y4T3IN5Gcis=; b=UTBYVA/45RHfSccFxPPyrNOGURSgiOt+npTcNbjnK1Se+idpzrHJTuDqDTLjSbbp7b H+1jQDSoqiCU4Lz91HzGn/q1RIqR/T9SoQmzlJD4bEQMQQq3rvWQrSg2/jXTLsAte4G5 ABldlzpcwATYN6rtkYH/qFlGlfZmYaSP09gGn4a5RwKRYR64X9VtpUV6ycjfk288G/gE u12Z2J4dh441eMWm4sgpmXw/eNH34Tii5Wrz34mdrq3fxIjqZd1ea8BSn4D6+xdOhZVn gviCV/yWUbKO9hM+oCMBgugqJMAjsKZiTvUNRMbDeYa0gdAzxuIGejsskI9IZhF6Q10C GbTw== X-Gm-Message-State: AAQBX9d4Or5rN6+ob+3dRAus9t/OQYwBMtal5nv02VFfuKPbqfhv2TNb DGevx6SpwuLBDiUDzGkBfUroCEqKU3uowaWIbyPLLg== X-Google-Smtp-Source: AKy350bLV9lITnSRR5EoNiVQUXa7iOsSEayZDWk5yBHeDU5nljypvqoPVYejGa2kG9BLkywHOlOW+gMW1Pn5GuaM4TY= X-Received: by 2002:a05:6122:d02:b0:440:54e1:5bf7 with SMTP id az2-20020a0561220d0200b0044054e15bf7mr981344vkb.4.1682076018914; Fri, 21 Apr 2023 04:20:18 -0700 (PDT) MIME-Version: 1.0 References: <20230421101415.5734-1-osalvador@suse.de> In-Reply-To: <20230421101415.5734-1-osalvador@suse.de> From: Alexander Potapenko Date: Fri, 21 Apr 2023 13:19:42 +0200 Message-ID: Subject: Re: [PATCH v4 0/3] page_owner: print stacks and their counter To: Oscar Salvador Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Vlastimil Babka , Eric Dumazet , Waiman Long , Suren Baghdasaryan , Marco Elver , Andrey Konovalov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: E6D5A8000C X-Stat-Signature: zrud3swou7jengkkba78bjoqh7rpp73j X-Rspam-User: X-HE-Tag: 1682076019-948383 X-HE-Meta: U2FsdGVkX19bJDvTtCw20o4nH55P7L3QwgPSoC2hQPDOQWgxYZ9/MhF1wh19mT/On6mR81L7NFpuvnA+paexb+4XUo/zWf9mEurd/55WuyhJXv0gvXYAT/W5EocvK8SJ8xLBbQlnAgPs325fZY5oBHyke6COKG0PceT4ip9e39HKoID759ETfBxsFUWtUTcOIO4q9zeKPFWW2kEfbGkoG6frrdPphxLhGPBm7uTTNv8JxzFM9e8lPGxuOOnuZa93cRN87AkjgrmycaGtvWaPxShjVvk2xjoSKNq8sk2fr4DfAAKtTBD0xLXYGRmxCh/IU1h0vQmwl3q7Dd9dJvAAxJz/R9QamYh0Jq5vjjakiRVQ4zcModOVumvd3Iqx60RQfLn7/Uuga1h2WV/kSLKLMkVOfkCV8l1YGF7TmwS2MlYd5PCOegVqEfdwvIiX8qv9ZFnkakbdcKvfo3AWtjdcAfIttiNEwQVaCzEdYaBIfLf35MSwGsAH6TSC96riPk9s9aUffzvmy9o5ooLxKc41GCJOt7CF6vXsaAkQ0gRtRZHG1Es4LZ5IfMnqK7GauA6RGOtGtakLAq0pCS5TRaxD4Q2UE5bsR8VMs8JqL8BsjshoU21AoWSeyxnb5eEchcFhqDVPv8AgBWLK7oWZlkMSl8yeJiC67Ks3RYRU0wrd1Q0x3uNy+GnhK2HXSWjVvhxGwBPLS+nVPhZXSNTHfkiffemtYkas5hF0B6Kg5M7LAUo+4hjPkmoHWmOKjnPRS3h8qr/W6ORHP4RD2Ub2qQwM4o8NgNFAcSI6i25aEXVhhlCKRl2lQpk6q1bgkrbW6Ki9MyZFGcxjlK9YZqeZmyig9Mn3hQDI7XP3ybBsJyys12bqSyMrYrDPz3mAU10P/BTha1FfarlI2DrbrwBIdw3nph1wzxKmnC1E7u+TpnloHx9KfC1gf0CZos+3ZGpK6wkI2wvZzDFafonW0TO9wZm NA/f9xde A1krBJBVWXV9Sg9nwVRcwyxixB5Oc+8T7ZWbZ0ZD/73gLKm2bInmSghISNPDhmfbocq7NuGhfqDqiPNn8evndRAZLCxO9JuhWPeDoSLW781oyOaEK9MWMwQRqplm3YgrsXpoSMnm3TiZC/ead5Epj48fQVVkYnpMuX6Y1mK71lGwh/vvQY4fer/GcV8mikiSBas+Ti9w744czM3RE3Sl/uXgk8ZlvwaBilvTqysaD/iE+VlxJi+VZziC9ZfADd6qinxbblYPC3JLQzE8= 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: On Fri, Apr 21, 2023 at 12:14=E2=80=AFPM Oscar Salvador = wrote: > > Changes v3 -> v4: > - Rebase (long time has passed) > - Use boolean instead of enum for action by Alexander Potapenko > - (I left some feedback untouched because it's been long and > would like to discuss it here now instead of re-vamping > and old thread) > > Changes v2 -> v3: > - Replace interface in favor of seq operations (suggested by Vlastim= il) > - Use debugfs interface to store/read valued (suggested by Ammar) > > Hi, > > page_owner is a great debug functionality tool that gets us to know > about all pages that have been allocated/freed and their stacktrace. > This comes very handy when e.g: debugging leaks, as with some scripting > we might be able to see those stacktraces that are allocating pages > but not freeing theme. > > In my experience, that is one of the most useful cases, but it can get > really tedious to screen through all pages aand try to reconstruct the > stack <-> allocated/freed relationship. There is a lot of noise > to cancel off. > > This patch aims to fix that by adding a new functionality into page_owner= . > What this does is to create a new read-only file "page_owner_stacks", > which prints only the allocating stacktraces and their counting, being th= at > the times the stacktrace has allocated - the times it has freed. > > So we have a clear overview of stacks <-> allocated/freed relationship > without the need to fiddle with pages and trying to match free stacktrace= s > with allocated stacktraces. > > This is achieved by adding a new refcount_t field in the stack_record str= uct, > incrementing that refcount_t everytime the same stacktrace allocates, > and decrementing it when it frees a page. Details can be seen in the > respective patches. I think the implementation of these counters is too specific to page_owner and is hard to use for any other purpose. If we decide to have them, there should be no page_owner-specific logic in the way we initialize/increment/decrement these counters. The thresholds in "mm,page_owner: Filter out stacks by a threshold counter" should also belong elsewhere. Given that no other stackdepot user needs these counters, maybe it should be cleaner to store an opaque struct along with the stack, passing its size to stack_depot_save(), and letting users access it directly using the stackdepot handler. I am also wondering if a separate hashtable mapping handlers to counters would solve the problem for you?