Received: by 2002:a05:7412:3b8b:b0:fc:a2b0:25d7 with SMTP id nd11csp624492rdb; Thu, 8 Feb 2024 16:36:15 -0800 (PST) X-Google-Smtp-Source: AGHT+IHvNZtqCpk+TTkqCV8ZfAUQYl3kAUPuZhQhqLsWB/TVTvgBIjEwP0OPjFqabrTfMfRnDuk4 X-Received: by 2002:a05:6358:591b:b0:176:a5f5:d266 with SMTP id g27-20020a056358591b00b00176a5f5d266mr976539rwf.6.1707438974957; Thu, 08 Feb 2024 16:36:14 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707438974; cv=pass; d=google.com; s=arc-20160816; b=BQ7N2y4mRNzsAmIPBT1YQPJxWwAxLtwwPgT0yDXlp93W1DZtCHOLKelT5K0OUGkFVO 8NOOIhcNGQLR706T8/x+kEdlhbr8jNUPlJGT1rIDR0EB6+2smmNIoxxlm0fSO6VeQRwb j4a858iIndTCNcg/i1Mkn+KbiSkNy5YImSh2L91lGntvOWeGPmmt+PtiEcle1X4Sz4a+ 1pC1ra3vXi339F3D9ZoVogY8QTOrsvQN9MTfNFEwz4s0jd1akzjrbCOAuHWspE7uTuIQ fBsIciLmvjugMm7PaJLCv725fmziQpv5pnFGBV4TMM/bV3F5wyigVPKQS4qOYDdxvPmC kCQA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=bLfd+V1tPZVOSY2cUl5n07cZFA949f5DwuJC/I/1MfI=; fh=ADKzkgzV6qkzRDOu7BEP6qSCNOB24SZqOcNbsD32XNs=; b=o9k6blq/cfPfAnAndnJC+iVVIUb7veWRAynHDXmHplbGKLBJnM0jjwdGKaf9ZBaeLx lmqhvJYnx06uwx3+4n6Q04PGavNjb/aRCPYl9YTO7KEQU1LVgJs/w22tjIlU6Aof9dYQ jL5xU5p4Yz9RMloD6c1mdeUvm+r/oYmnC/LkAHE7mBin99nQAvBQQS9erWNfYzuWoeV5 /Z99Q1hgCczVAFjXGXFcGZTfD6WPa1xyhS7pqX/m/inD5fb3zn26WXLN6Npdbi8oWHgp HgDiFGFzKSxrk4oDRHUeVdiiiVPPgIViB38n3HGTeUalQ5vfPvdrZ1EuycdxTILTbd+v 5zaQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=FWJXAuSJ; arc=pass (i=1 dkim=pass dkdomain=linux-foundation.org); spf=pass (google.com: domain of linux-kernel+bounces-58903-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-58903-linux.lists.archive=gmail.com@vger.kernel.org" X-Forwarded-Encrypted: i=2; AJvYcCV1Qt4fG1aHoj/1kwIbmqXe2m+89rs74YUryPBxp6VLMljdu1dREU6rTDQImNDxHSSOaudZvbKT6Va1tR5RveFePaYGGo5KpzRscdMyiA== Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id l4-20020a63ba44000000b005dc4d8a8f29si680717pgu.664.2024.02.08.16.36.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Feb 2024 16:36:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-58903-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=FWJXAuSJ; arc=pass (i=1 dkim=pass dkdomain=linux-foundation.org); spf=pass (google.com: domain of linux-kernel+bounces-58903-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-58903-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 6CD1A28BE6D for ; Fri, 9 Feb 2024 00:28:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2AEEB37E; Fri, 9 Feb 2024 00:28:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="FWJXAuSJ" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC484364 for ; Fri, 9 Feb 2024 00:28:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707438499; cv=none; b=Me6cnjUamdwIaMh0PIfl7y2roKoJswBU72TQPPCYGBh2/fmhJmznTzMsd8RI6ESwhWKvxyRnj79zLlt8X9WYA3hdcCeIBXNcGPHwyCXpPJabLCE8+ILJnMiqV7czK5fpCdXBjOK+LmseQx62mLw1JivjIndH/tgUZKq4AbnrJsQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707438499; c=relaxed/simple; bh=11T3RfqVBk/00J32ASxKzhqAcS03aS5TfH8i2dHZWXg=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=GMMt7PGzKTlwd3yI8f2Tjc/OxuAs3XLPf/yWlHsHsqutZ+KQqC4qFo1DqfWiQUpR80TfPEXTgcYFBhEr6rw4qhcC8ghnZhG/4jiOrXndixfV/VjQAVSosp3KLBM6Rc0xB23WHToEy6wIseO2CT1uggg4kOjvHQZLvDhUE3k3ubU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=FWJXAuSJ; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CBB8C433C7; Fri, 9 Feb 2024 00:28:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1707438499; bh=11T3RfqVBk/00J32ASxKzhqAcS03aS5TfH8i2dHZWXg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=FWJXAuSJWVE93DhOHvg+/cLaQAIitptg/4rNbc99uElVG5kHmZlZbuPuwENF7F+CO VvvzASS76WReP2nLQA1TE/1yLKePgkiUteXzC9sxCl4YjO26j7cDKUfcl41IOuxX0R CfYlvU6fLhBQKc7ag499ReV+f+m8VJzbSA8cViQc= Date: Thu, 8 Feb 2024 16:28:18 -0800 From: Andrew Morton To: Oscar Salvador Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Vlastimil Babka , Marco Elver , Andrey Konovalov , Alexander Potapenko Subject: Re: [PATCH v7 0/4] page_owner: print stacks and their outstanding allocations Message-Id: <20240208162818.369c7abc3ecb06d49adaeebb@linux-foundation.org> In-Reply-To: <20240208234539.19113-1-osalvador@suse.de> References: <20240208234539.19113-1-osalvador@suse.de> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 9 Feb 2024 00:45:35 +0100 Oscar Salvador wrote: > page_owner is a great debug functionality tool that lets us know > about all pages that have been allocated/freed and their specific > stacktrace. > This comes very handy when debugging memory leaks, since with > some scripting we can see the outstanding allocations, which might point > to a memory leak. > > In my experience, that is one of the most useful cases, but it can get > really tedious to screen through all pages and try to reconstruct the > stack <-> allocated/freed relationship, becoming most of the time a > daunting and slow process when we have tons of allocation/free operations. > > This patchset aims to ease that by adding a new functionality into > page_owner. > This functionality creates a new read-only file called "page_owner_stacks", The full path would be appreciated. > which prints out all the stacks followed by their outstanding number > of allocations (being that the times the stacktrace has allocated > but not freed yet). > This gives us a clear and a quick overview of stacks <-> allocated/free. > > We take advantage of the new refcount_f field that stack_record struct > gained, and increment/decrement the stack refcount on every > __set_page_owner() (alloc operation) and __reset_page_owner (free operation) > call. > > Unfortunately, we cannot use the new stackdepot api > STACK_DEPOT_FLAG_{GET,PUT} because it does not fulfill page_owner needs, > meaning we would have to special case things, at which point > makes more sense for page_owner to do its own {dec,inc}rementing > of the stacks. > E.g: Using STACK_DEPOT_FLAG_PUT, once the refcount reaches 0, > such stack gets evicted, so page_owner would lose information. > > This patch also creates a new file called 'page_owner_threshold'. > By writing a value to it, the stacks which refcount is below such > value will be filtered out. > > In order to better exercise the path in stack_depot_get_next_stack(), > I artificially filled the buckets with more than one stack, making sure > I was getting all of then when reading from it. > > On a side note, stack_depot_get_next_stack() could be somehow reconstructed > to be in page_owner code, but we would have to move stack_table > into the header, so page_owner can access it. > I can do that if that's preferred, so stackdepot.c would not get "poluted". > > A PoC can be found below: > > # cat /sys/kernel/debug/page_owner_stacks > page_owner_full_stacks.txt Oh, there it is. I wonder why we didn't use /sys/kernel/mm/ Would a new /sys/kernel/debug/page_owner_something/ be a good idea? We might add more things later. Then it can be /sys/kernel/debug/page_owner_something/full_stacks. /sys/kernel/debug/page_owner/ would be nice, but it's too late for that. > Oscar Salvador (4): > lib/stackdepot: Move stack_record struct definition into the header > mm,page_owner: Implement the tracking of the stacks count > mm,page_owner: Display all stacks and their count > mm,page_owner: Filter out stacks by a threshold > > include/linux/stackdepot.h | 72 ++++++++++++++++++++ > lib/stackdepot.c | 97 ++++++++++++++------------ > mm/page_owner.c | 136 +++++++++++++++++++++++++++++++++++++ > 3 files changed, 262 insertions(+), 43 deletions(-) Documentation/mm/page_owner.rst?