From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932700AbbCQKYJ (ORCPT ); Tue, 17 Mar 2015 06:24:09 -0400 Received: from e28smtp09.in.ibm.com ([122.248.162.9]:36277 "EHLO e28smtp09.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932277AbbCQKYE (ORCPT ); Tue, 17 Mar 2015 06:24:04 -0400 From: "Aneesh Kumar K.V" To: Stefan Strogin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Joonsoo Kim , Andrew Morton , Marek Szyprowski , Michal Nazarewicz , Laurent Pinchart , Dmitry Safonov , Pintu Kumar , Weijie Yang , Laura Abbott , SeongJae Park , Hui Zhu , Minchan Kim , Dyasly Sergey , Vyacheslav Tyrtov , Aleksei Mateosian , gregory.0xf0@gmail.com, sasha.levin@oracle.com, gioh.kim@lge.com, pavel@ucw.cz, stefan.strogin@gmail.com Subject: Re: [PATCH v3 3/4] mm: cma: add list of currently allocated CMA buffers to debugfs In-Reply-To: <54FEF163.6000602@partner.samsung.com> References: <1fe64ae6f12eeda1c2aa59daea7f89e57e0e35a9.1424802755.git.s.strogin@partner.samsung.com> <87pp8qa1ab.fsf@linux.vnet.ibm.com> <54FEF163.6000602@partner.samsung.com> User-Agent: Notmuch/0.19+30~gd241a48 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Tue, 17 Mar 2015 15:53:56 +0530 Message-ID: <87zj7bapmr.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15031710-0033-0000-0000-000004C6B0F0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Stefan Strogin writes: > Hi Aneesh, > > On 03/03/15 12:16, Aneesh Kumar K.V wrote: >> Stefan Strogin writes: >> >>> When CONFIG_CMA_BUFFER_LIST is configured a file is added to debugfs: >>> /sys/kernel/debug/cma/cma-/buffers contains a list of currently allocated >>> CMA buffers for each CMA region (N stands for number of CMA region). >>> >>> Format is: >>> - ( kB), allocated by () >>> >>> When CONFIG_CMA_ALLOC_STACKTRACE is configured then stack traces are saved when >>> the allocations are made. The stack traces are added to cma/cma-/buffers >>> for each buffer list entry. >>> >>> Example: >>> >>> root@debian:/sys/kernel/debug/cma# cat cma-0/buffers >>> 0x2f400000 - 0x2f417000 (92 kB), allocated by pid 1 (swapper/0) >>> [] cma_alloc+0x1bb/0x200 >>> [] dma_alloc_from_contiguous+0x3a/0x40 >>> [] dma_generic_alloc_coherent+0x89/0x160 >>> [] dmam_alloc_coherent+0xbe/0x100 >>> [] ahci_port_start+0xe2/0x210 >>> [] ata_host_start.part.28+0xc0/0x1a0 >>> [] ata_host_activate+0xd0/0x110 >>> [] ahci_host_activate+0x3f/0x170 >>> [] ahci_init_one+0x764/0xab0 >>> [] pci_device_probe+0x6f/0xd0 >>> [] driver_probe_device+0x68/0x210 >>> [] __driver_attach+0x79/0x80 >>> [] bus_for_each_dev+0x4f/0x80 >>> [] driver_attach+0x1e/0x20 >>> [] bus_add_driver+0x157/0x200 >>> [] driver_register+0x5d/0xf0 >>> <...> >> >> A perf record -g will also give this information right ? To use this >> feature, one need to recompile the kernel anyway. So why not assume that >> user can always rerun the test with perf record -g and find the cma >> allocation point stack trace ? >> >> -aneesh >> > > Excuse me for the delay. > I thought that 'perf record ' gathers data only for a command > that it runs, does it? But we want to have information about all the > allocations and releases from the boot time. >>From boot time makes it interesting. Otherwise you could use perf record. For ex: ./perf record -e kmem:kmalloc -g -a ./perf script jbd2/dm-3-8 7666 [000] 4666.621521: kmem:kmalloc: call_site=c0000000003ce108 ptr=0xc000000fcd646360 bytes_req=96 bytes_alloc=96 gfp_flags=GFP_NOFS|GFP_ZERO 27f1dc .__kmalloc (/boot/vmlinux) 0 [unknown] ([unknown]) 3de108 .ext4_find_extent (/boot/vmlinux) 3e4038 .ext4_ext_map_blocks (/boot/vmlinux) 3ab388 .ext4_map_blocks (/boot/vmlinux) 3ab970 ._ext4_get_block (/boot/vmlinux) 2df7e0 .generic_block_bmap (/boot/vmlinux) 3a7f4c .ext4_bmap (/boot/vmlinux) 2ba744 .bmap (/boot/vmlinux) 4293d4 .jbd2_journal_bmap (/boot/vmlinux) 41df84 .jbd2_journal_commit_transaction (/boot/vmlinux) 427620 .kjournald2 (/boot/vmlinux) fbfa4 .kthread (/boot/vmlinux) 19568 .ret_from_kernel_thread (/boot/vmlinux) .... >IMHO it would be more > reasonable to use ftrace for that. But after all the patch enables to > see not a history of allocations and deallocations but a current state > of CMA region. > As to recompilation, for example in our division this feature is enabled > by default among other CONFIG_*_DEBUG features in debug versions of kernel.