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 0665BC4829A for ; Tue, 13 Feb 2024 08:39:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 793566B0089; Tue, 13 Feb 2024 03:39:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 742F56B008A; Tue, 13 Feb 2024 03:39:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60B136B0092; Tue, 13 Feb 2024 03:39:22 -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 52D306B0089 for ; Tue, 13 Feb 2024 03:39:22 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EE40F16092D for ; Tue, 13 Feb 2024 08:39:21 +0000 (UTC) X-FDA: 81786131322.25.1E98056 Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) by imf18.hostedemail.com (Postfix) with ESMTP id 3C45A1C0014 for ; Tue, 13 Feb 2024 08:39:19 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BRrQSddg; spf=pass (imf18.hostedemail.com: domain of elver@google.com designates 209.85.217.49 as permitted sender) smtp.mailfrom=elver@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=1707813560; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fyqfWeybHMGs698ToWhPG+TlUwHa8zyGlvb2w4RdNr8=; b=4nvvB5uUrTZ3nhnH5oFy4MCOCR9u750HStOSGN//BMpD5nLCsWg589psL9e3yO8ANcj+oy 64bB6o6OBMcNDk7wa7Ljr1bF21KcapWjfuetHMo3TU9b2F/4kpFQZ4RvOuIrXTcbQ13jBp ndSHi5LDGbtAm1gFg4biNa2oVzBCGTg= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BRrQSddg; spf=pass (imf18.hostedemail.com: domain of elver@google.com designates 209.85.217.49 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707813560; a=rsa-sha256; cv=none; b=CY367Ld1qPD2Sf+pWUooDH2OCu1FRsR5H2+sPL3/JFWgmafWQMpOgPOouFFWdyi6JEQbO3 KuiN1q2e7IeeSMFo9s4mueHObanW60nSDqnWliClGxj2oR+vQ6RmQNHaseBghQgg00+fHw Ue7164lIHGWIe+f71msAEn27SAJaOnI= Received: by mail-vs1-f49.google.com with SMTP id ada2fe7eead31-46d331e3fd2so2314320137.0 for ; Tue, 13 Feb 2024 00:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707813559; x=1708418359; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fyqfWeybHMGs698ToWhPG+TlUwHa8zyGlvb2w4RdNr8=; b=BRrQSddgv+rXUPesBbK6+3J5cLxQgvC3/3tIWtSURfQmgJPmsvwcdh796NuTi60Bch ubHUE/nfTUWkwgNPU8Y6HlUxfATRg7vYJKqiMmSljr4rW8OEzS8Lsl74VzDZPowU59fG bq8V4EiQwAx4xwAgpyrOgNAZlr0n5I786uFNKQ8efjqdxUyt/9kYZ8hjJytulNNowzt+ cFFi3tDg1HCPYQsc8t9nbtLsycoRjsU4EOYYtGHAlYhV4+GlTpHplZTk1cLG/SL0hAnP 85MpaZdJuZZ0W9j2C1CwU+M6Bus27UHwk6eoqIoOFVZlFkP4xyT0AuGbmGk64wh/VIuP LXzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707813559; x=1708418359; h=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=fyqfWeybHMGs698ToWhPG+TlUwHa8zyGlvb2w4RdNr8=; b=iOaRnDHZpV2KvSFW8kLr/g45Tl5sFfpR8tfwRLUAR1iIWn4dkvxYrPc672HN1hVDMj 2kcLwmEmZxkv4JMWfWbBzTToYnYYJqMAljvgxvtQdqSsmg+DvhesV33bo9MV1IUeOGWD ktVjERAYx3YYjzGvDczMJ/0Yqg/b5EyKjwx+QPHHrqaoENL5mHMxsf+lO/kvqnlT5+x8 2SfHKNrYMyA0yU7P6G1mlTGlh2S7cBwFCPu6hAC6EB8kge3Pk4CzDTQ6raOXyqBanvMg zIzn5h/q6hI/JAnXfuGUTvSOYgqGIP5tDhgpd+0P3pWJhPQdBHjhzWkPWz7+7Cqrtjkh emjA== X-Forwarded-Encrypted: i=1; AJvYcCXPa+3KH1lw1N3ShdR4OP9y+stNPC0g58QU1wSIGLGM7wNVnRkUsuJy4rbn6xzOzwo8YNItFnf6G+cRdHiM7yEr5wg= X-Gm-Message-State: AOJu0YxlPEmCYdHFnAP+VIR9TKqZu/6a/iaMNspbuAdzfNS4OfG+LR1o Kt/9jpRU4Klp3Eu0jB05AkiIR7tF7rDNQMfp+P1MmeflknSIBG779aD4Yadjg+3nMlOZkaTB10E TZ/7kXvsJ26t/z9f/7zKpNRffTMEIZZREUpBc X-Google-Smtp-Source: AGHT+IHaStbYhTfQCh40cjCa00p/FVTyac3jnxlHzQn7kytpMqveLeq2NVuvSBF9mJ7hURK4BwkBkjTyvRVCO4CUTsc= X-Received: by 2002:a05:6102:2265:b0:46d:2675:5ae6 with SMTP id v5-20020a056102226500b0046d26755ae6mr1249474vsd.15.1707813559082; Tue, 13 Feb 2024 00:39:19 -0800 (PST) MIME-Version: 1.0 References: <20240212223029.30769-1-osalvador@suse.de> <20240212223029.30769-4-osalvador@suse.de> In-Reply-To: <20240212223029.30769-4-osalvador@suse.de> From: Marco Elver Date: Tue, 13 Feb 2024 09:38:43 +0100 Message-ID: Subject: Re: [PATCH v8 3/5] mm,page_owner: Display all stacks and their count To: Oscar Salvador Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , Vlastimil Babka , Andrey Konovalov , Alexander Potapenko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 3C45A1C0014 X-Rspam-User: X-Stat-Signature: 1q5apicc6ytouuhk8fs4g3nr4gx4neam X-Rspamd-Server: rspam01 X-HE-Tag: 1707813559-997369 X-HE-Meta: U2FsdGVkX19YH+5qdOcxpNdxKch8zcW3vD3qV5rZWhFI/UXLL631uysLINiVwAVJ6xfN7msJZzTC3OAE4WfIWjxNIhvTiJmENLLWYvKDzlwWTARy1nJbnzPOAOdpvaNJwRLfoxRDuyGck6qefHGm9WkCPFz8FjmpzEIctQ+PUvlE0cQItyli3R5kqGxWDLptRHJ5WlQkOoejDj42jLeiO5G6K0gJysjfuytsIOEUqjrr6NISrpszdpGESUIkdpYtP/ub1qXkiAUw+/twKmQo07h26lQt5KeR5fr/3zMPmGT55mPiBv2XPY7u+UpE9AOdDjaAL+z97Byn8aDwb+nistHOfw67NQAIVWydch4zgTRkhhTvvO0K2gUYQUjrjKLXg1QRNm9N8AzleTB5X/QfczTv5KYwEf/ET06XseEEZBTEVBLDV4DvrIqm+1fsB1CEBWtRSxXb+2Xg8td1E0YuLTMcZYT80xeGZ6GAse//whuWMpKrpw1qF8Ll+1WjSIUx8F/B8FVBAg62XFBa18ZHhoAmDQz0YLz3fEDKmcJCfHHUEh3gOboXx4+kxdpxuZTzCWmDTqs1wigo6UbwjLp/bZHyeukB78yuPzvcsgbpuLh501eZcUg6Cm9c0j6NIw3QdLpJkumIMCMmsrMyJmeyORTEgvybM6pO5iqJosf6P8ZkLjs9MMhhh4d0CctmXpb0HPBi7WqnLc4+YFGUUcB0epe4OHdvpeyvuwzeN/CJeqJOcIzD8p7l1xXfYgFmFwHgaX6blVgn7UHsNnxDhuJn5Je3ujqFpR/G0GsJUhlfX1by/Sgo680AvE++DdIMyh4CO8EYgLOl2yeA5/yefso0o48U91sWHgOOSwHzM68GHtLjkYrH8Gk6OLBM05yibqSxf0QmMF9FAXBHPt0q4wNeVxJynSwWhfvVDZa3za/wBc3/vY+kanj9gqLCFn6ZLGsHq5hjM1wKVwJfZ3eV8Yu DBterDzg TtI/6aRIgJ3KYrKxUXqZ6A8rBXljXCUIdG9XKduZFAmZ2YrDemkxMrlT3kqkfkt2PzCaaiAi5IWBm9UPPVRYL7WXmmq20dmQLUcy6UYw13YXm4ElhKo+0EvqleqT3eFIeImIWNFqG5UixdW4Y/ku61COT5uDark4O8JrOJFi+79+sktbcFvtsGCUqyr67Te+BUNSrvtrLoJfqs9+v4WCIv1dx/BxHx/3Ifz0EOomvNtJy+OWLFaAJDEoyZ59KhAMhsgj/P7frcJzsp1FfFe2w9iOvO7VE8m08VnUmki7/r8ydpUoQWiaF93bvn4bWlUhMHeVvsax7lC7zSFw= 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 Mon, 12 Feb 2024 at 23:29, Oscar Salvador wrote: > > This patch adds a new directory called 'page_owner_stacks' under > /sys/kernel/debug/, with a file called 'show_stacks' in it. > Reading from that file will show all stacks that were added by page_owner > followed by their counting, giving us a clear overview of stack <-> count > relationship. > > E.g: > > prep_new_page+0xa9/0x120 > get_page_from_freelist+0x801/0x2210 > __alloc_pages+0x18b/0x350 > alloc_pages_mpol+0x91/0x1f0 > folio_alloc+0x14/0x50 > filemap_alloc_folio+0xb2/0x100 > __filemap_get_folio+0x14a/0x490 > ext4_write_begin+0xbd/0x4b0 [ext4] > generic_perform_write+0xc1/0x1e0 > ext4_buffered_write_iter+0x68/0xe0 [ext4] > ext4_file_write_iter+0x70/0x740 [ext4] > vfs_write+0x33d/0x420 > ksys_write+0xa5/0xe0 > do_syscall_64+0x80/0x160 > entry_SYSCALL_64_after_hwframe+0x6e/0x76 > stack_count: 4578 > > The seq stack_{start,next} functions will iterate through the list > stack_list in order to print all stacks. > > Signed-off-by: Oscar Salvador Acked-by: Marco Elver Minor comments below. > --- > mm/page_owner.c | 99 ++++++++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 98 insertions(+), 1 deletion(-) > > diff --git a/mm/page_owner.c b/mm/page_owner.c > index 7d1b3f75cef3..3e4b7cd7c8f8 100644 > --- a/mm/page_owner.c > +++ b/mm/page_owner.c > @@ -84,7 +84,12 @@ static void add_stack_record_to_list(struct stack_record *stack_record) > stack_list = stack; > } else { > stack->next = stack_list; > - stack_list = stack; > + /* This pairs with smp_load_acquire() from function Comment should be /* * ... */ (Unless in networking or other special subsystems with their own comment style.) > + * stack_start(). This guarantees that stack_start() > + * will see an updated stack_list before starting to > + * traverse the list. > + */ > + smp_store_release(&stack_list, stack); > } > spin_unlock_irqrestore(&stack_list_lock, flags); > } > @@ -792,8 +797,97 @@ static const struct file_operations proc_page_owner_operations = { > .llseek = lseek_page_owner, > }; > > +static void *stack_start(struct seq_file *m, loff_t *ppos) > +{ > + struct stack *stack; > + > + if (*ppos == -1UL) > + return NULL; > + > + if (!*ppos) { > + /* > + * This pairs with smp_store_release() from function > + * add_stack_record_to_list(), so we get a consistent > + * value of stack_list. > + */ > + stack = smp_load_acquire(&stack_list); I'm not sure if it'd make your code simpler or not: there is for singly-linked linked lists, although the code to manage the list is simple enough I'm indifferent here. Only consider it if it helps you make the code simpler. > + } else { > + stack = m->private; > + stack = stack->next; > + } > + > + m->private = stack; > + > + return stack; > +} > + > +static void *stack_next(struct seq_file *m, void *v, loff_t *ppos) > +{ > + struct stack *stack = v; > + > + stack = stack->next; > + *ppos = stack ? *ppos + 1 : -1UL; > + m->private = stack; > + > + return stack; > +} > + > +static int stack_print(struct seq_file *m, void *v) > +{ > + char *buf; > + int ret = 0; > + struct stack *stack = v; > + struct stack_record *stack_record = stack->stack_record; > + > + if (!stack_record->size || stack_record->size < 0 || > + refcount_read(&stack_record->count) < 2) > + return 0; > + > + buf = kzalloc(PAGE_SIZE, GFP_KERNEL); > + > + ret += stack_trace_snprint(buf, PAGE_SIZE, stack_record->entries, > + stack_record->size, 0); > + if (!ret) > + goto out; > + > + scnprintf(buf + ret, PAGE_SIZE - ret, "stack_count: %d\n\n", > + refcount_read(&stack_record->count)); > + > + seq_printf(m, buf); > + seq_puts(m, "\n\n"); > +out: > + kfree(buf); > + > + return 0; > +} > + > +static void stack_stop(struct seq_file *m, void *v) > +{ > +} Is this function even needed if it's empty? I recall there were some boilerplate "nop" functions that could be used. > +static const struct seq_operations page_owner_stack_op = { > + .start = stack_start, > + .next = stack_next, > + .stop = stack_stop, > + .show = stack_print > +}; > + > +static int page_owner_stack_open(struct inode *inode, struct file *file) > +{ > + return seq_open_private(file, &page_owner_stack_op, 0); > +} > + > +static const struct file_operations page_owner_stack_operations = { > + .open = page_owner_stack_open, > + .read = seq_read, > + .llseek = seq_lseek, > + .release = seq_release, > +}; > + > static int __init pageowner_init(void) > { > + struct dentry *dir; > + > if (!static_branch_unlikely(&page_owner_inited)) { > pr_info("page_owner is disabled\n"); > return 0; > @@ -801,6 +895,9 @@ static int __init pageowner_init(void) > > debugfs_create_file("page_owner", 0400, NULL, NULL, > &proc_page_owner_operations); > + dir = debugfs_create_dir("page_owner_stacks", NULL); > + debugfs_create_file("show_stacks", 0400, dir, NULL, > + &page_owner_stack_operations); > > return 0; > } > -- > 2.43.0 >