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 5B6DDC433FE for ; Sun, 27 Feb 2022 03:49:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9734A8D0018; Sat, 26 Feb 2022 22:49:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 922008D0007; Sat, 26 Feb 2022 22:49:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 812458D0018; Sat, 26 Feb 2022 22:49:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.26]) by kanga.kvack.org (Postfix) with ESMTP id 701D08D0007 for ; Sat, 26 Feb 2022 22:49:50 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 374A1806E4 for ; Sun, 27 Feb 2022 03:49:50 +0000 (UTC) X-FDA: 79187180940.02.1C4BAD3 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by imf21.hostedemail.com (Postfix) with ESMTP id 9E2161C0002 for ; Sun, 27 Feb 2022 03:49:49 +0000 (UTC) Received: by mail-pg1-f171.google.com with SMTP id 195so8474433pgc.6 for ; Sat, 26 Feb 2022 19:49:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Ek02eCmAnj7Z2ZCUVWU1x+42laMB9rYJ1kTYghRSfoY=; b=l5LWHNq/cqCHFY23g+qTLqYtg2Mgv7d2GowvDp/LrdHdjfCCJaLU9EkWMTemApxWso L7mRV+GY4NUJAOnJh+SyFoQ2AZbCvtq05jfttc8/XZcF00Ud36eKQzeSuZjVoEZHvZ++ 8YfT3V4zEtI1guC9HOJfif2AxnmnL4ojUtunB/s9X0npaZci0zEQ2mpCn/QlbK+Z+rHf sDmNpLcXXv4B+GTZTvLpRvWn4EeuaZVBpIp78cUOh+oHp0hB/7XFRhHeYX8DlFERAUXO q1bgLt/dJHQCtgwP2G4oZvEMeHErFuP8cwaFoAvsmutlmF8RAK37gPgqxdt3ungrgXFy nfmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Ek02eCmAnj7Z2ZCUVWU1x+42laMB9rYJ1kTYghRSfoY=; b=vnw3HACw/7EvrhiXYAmB8nrzhy4F1NAGwTd7HL50ynxZk+FzquFItVRUtaj+4EXOfE YRAxUASH2Ii87L9fHT4sGKZt21pLFR5SZyN1wc/RtuTeDShwAdZC1TDZpsuzLI7osUvu LFUgqFjx6zoJ4R/aeo2hYekekqupIpVfdlcg47jZ8ziT7/X7RaGi29wkbzW1Fj7ESWVF l1XZb+1VSArjljSvaiUrGkRcFJOaLHvswU0YnYmlvmAfLgtuymipyYbEEDM9Gd9pff02 /cAWOHkzXNo546Htrk7G9w8xbF3O46aJ7Y8VhLajW1xDy0xiXuaoOb1vNm95IGkR3QLf 42pA== X-Gm-Message-State: AOAM530owYFAbM7u7Kfbvvy2ItnK7AKu/Z47xbrqEs8xKWRWxthXXHKP eDCD2DmYu/Kq+1c9Np7tSJ8= X-Google-Smtp-Source: ABdhPJzzuUAQA+T6PXrJ+bSAiek9oD6PjwdZxcLhDQsJbsFHLYu0HQ9stXDcYMMzLIgqbH/QjRw64A== X-Received: by 2002:aa7:8a4d:0:b0:4f2:6d3f:5fe3 with SMTP id n13-20020aa78a4d000000b004f26d3f5fe3mr15220064pfa.48.1645933788551; Sat, 26 Feb 2022 19:49:48 -0800 (PST) Received: from ip-172-31-19-208.ap-northeast-1.compute.internal (ec2-18-181-137-102.ap-northeast-1.compute.amazonaws.com. [18.181.137.102]) by smtp.gmail.com with ESMTPSA id lt8-20020a17090b354800b001bc509e0085sm12606983pjb.21.2022.02.26.19.49.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 26 Feb 2022 19:49:48 -0800 (PST) Date: Sun, 27 Feb 2022 03:49:42 +0000 From: Hyeonggon Yoo <42.hyeyoo@gmail.com> To: Vlastimil Babka Cc: David Rientjes , Christoph Lameter , Joonsoo Kim , Pekka Enberg , Roman Gushchin , Andrew Morton , linux-mm@kvack.org, patches@lists.linux.dev, linux-kernel@vger.kernel.org, Oliver Glitta , Faiyaz Mohammed , Jonathan Corbet , Randy Dunlap , linux-doc@vger.kernel.org Subject: Re: [PATCH 5/5] slab, documentation: add description of debugfs files for SLUB caches Message-ID: References: <20220225180318.20594-1-vbabka@suse.cz> <20220225180318.20594-6-vbabka@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220225180318.20594-6-vbabka@suse.cz> X-Rspamd-Queue-Id: 9E2161C0002 X-Stat-Signature: i1qyuynddjoi7sifpm18ikwdr1x5czzy X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="l5LWHNq/"; spf=pass (imf21.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.215.171 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam07 X-HE-Tag: 1645933789-774800 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, Feb 25, 2022 at 07:03:18PM +0100, Vlastimil Babka wrote: > From: Oliver Glitta > > Add description of debugfs files alloc_traces and free_traces > to SLUB cache documentation. > > [ vbabka@suse.cz: some rewording ] > > Signed-off-by: Oliver Glitta > Signed-off-by: Vlastimil Babka > Cc: Jonathan Corbet > Cc: Randy Dunlap > Cc: linux-doc@vger.kernel.org > --- > Documentation/vm/slub.rst | 61 +++++++++++++++++++++++++++++++++++++++ > 1 file changed, 61 insertions(+) > > diff --git a/Documentation/vm/slub.rst b/Documentation/vm/slub.rst > index d3028554b1e9..2b2b931e59fc 100644 > --- a/Documentation/vm/slub.rst > +++ b/Documentation/vm/slub.rst > @@ -384,5 +384,66 @@ c) Execute ``slabinfo-gnuplot.sh`` in '-t' mode, passing all of the > 40,60`` range will plot only samples collected between 40th and > 60th seconds). > > + > +DebugFS files for SLUB > +====================== > + > +For more information about current state of SLUB caches with the user tracking > +debug option enabled, debugfs files are available, typically under > +/sys/kernel/debug/slab// (created only for caches with enabled user > +tracking). There are 2 types of these files with the following debug > +information: > + > +1. alloc_traces:: > + > + Prints information about unique allocation traces of the currently > + allocated objects. The output is sorted by frequency of each trace. > + > + Information in the output: > + Number of objects, allocating function, minimal/average/maximal jiffies since alloc, > + pid range of the allocating processes, cpu mask of allocating cpus, and stack trace. > + > + Example::: > + > + 1085 populate_error_injection_list+0x97/0x110 age=166678/166680/166682 pid=1 cpus=1:: > + __slab_alloc+0x6d/0x90 > + kmem_cache_alloc_trace+0x2eb/0x300 > + populate_error_injection_list+0x97/0x110 > + init_error_injection+0x1b/0x71 > + do_one_initcall+0x5f/0x2d0 > + kernel_init_freeable+0x26f/0x2d7 > + kernel_init+0xe/0x118 > + ret_from_fork+0x22/0x30 > + > + > +2. free_traces:: > + > + Prints information about unique free traces of the currently free objects, > + sorted by their frequency. > + I'm not sure that it's traces of the "currently free objects". static int slab_debug_trace_open(struct inode *inode, struct file *filep) { [...] obj_map = bitmap_alloc(oo_objects(s->oo), GFP_KERNEL); [...] for_each_kmem_cache_node(s, node, n) { unsigned long flags; struct slab *slab; if (!atomic_long_read(&n->nr_slabs)) continue; spin_lock_irqsave(&n->list_lock, flags); list_for_each_entry(slab, &n->partial, slab_list) process_slab(t, s, slab, alloc, obj_map); list_for_each_entry(slab, &n->full, slab_list) process_slab(t, s, slab, alloc, obj_map); spin_unlock_irqrestore(&n->list_lock, flags); } [...] } static void __fill_map(unsigned long *obj_map, struct kmem_cache *s, struct slab *slab) { void *addr = slab_address(slab); void *p; bitmap_zero(obj_map, slab->objects); for (p = slab->freelist; p; p = get_freepointer(s, p)) set_bit(__obj_to_index(s, addr, p), obj_map); } static void process_slab(struct loc_track *t, struct kmem_cache *s, struct slab *slab, enum track_item alloc, unsigned long *obj_map) { void *addr = slab_address(slab); void *p; __fill_map(obj_map, s, slab); for_each_object(p, s, addr, slab->objects) if (!test_bit(__obj_to_index(s, addr, p), obj_map)) add_location(t, s, get_track(s, p, alloc)); } I think it's not traces of "currently free objects" because index bit of free objects are set in obj_map bitmap? It's weird but it's traces of allocated objects that have been freed at least once (or ) I think we can fix the code or doc? Please tell me if I'm missing something :) > + Information in the output: > + Number of objects, freeing function, minimal/average/maximal jiffies since free, > + pid range of the freeing processes, cpu mask of freeing cpus, and stack trace. > + > + Example::: > + > + 51 acpi_ut_update_ref_count+0x6a6/0x782 age=236886/237027/237772 pid=1 cpus=1 > + kfree+0x2db/0x420 > + acpi_ut_update_ref_count+0x6a6/0x782 > + acpi_ut_update_object_reference+0x1ad/0x234 > + acpi_ut_remove_reference+0x7d/0x84 > + acpi_rs_get_prt_method_data+0x97/0xd6 > + acpi_get_irq_routing_table+0x82/0xc4 > + acpi_pci_irq_find_prt_entry+0x8e/0x2e0 > + acpi_pci_irq_lookup+0x3a/0x1e0 > + acpi_pci_irq_enable+0x77/0x240 > + pcibios_enable_device+0x39/0x40 > + do_pci_enable_device.part.0+0x5d/0xe0 > + pci_enable_device_flags+0xfc/0x120 > + pci_enable_device+0x13/0x20 > + virtio_pci_probe+0x9e/0x170 > + local_pci_probe+0x48/0x80 > + pci_device_probe+0x105/0x1c0 > + Everything else looks nice! > Christoph Lameter, May 30, 2007 > Sergey Senozhatsky, October 23, 2015 > -- > 2.35.1 > > -- Thank you, You are awesome! Hyeonggon :-)