From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753283AbbCJN2P (ORCPT <rfc822;w@1wt.eu>);
	Tue, 10 Mar 2015 09:28:15 -0400
Received: from mailout2.w1.samsung.com ([210.118.77.12]:55205 "EHLO
	mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751582AbbCJN2L (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 10 Mar 2015 09:28:11 -0400
X-AuditID: cbfec7f4-b7f126d000001e9a-07-54fef0d84d79
Message-id: <54FEF163.6000602@partner.samsung.com>
Date: Tue, 10 Mar 2015 16:28:03 +0300
From: Stefan Strogin <s.strogin@partner.samsung.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
 Thunderbird/31.5.0
MIME-version: 1.0
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        Michal Nazarewicz <mina86@mina86.com>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Dmitry Safonov <d.safonov@partner.samsung.com>,
        Pintu Kumar <pintu.k@samsung.com>,
        Weijie Yang <weijie.yang@samsung.com>,
        Laura Abbott <lauraa@codeaurora.org>,
        SeongJae Park <sj38.park@gmail.com>, Hui Zhu <zhuhui@xiaomi.com>,
        Minchan Kim <minchan@kernel.org>, Dyasly Sergey <s.dyasly@samsung.com>,
        Vyacheslav Tyrtov <v.tyrtov@samsung.com>,
        Aleksei Mateosian <a.mateosian@samsung.com>, 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
References: <cover.1424802755.git.s.strogin@partner.samsung.com>
 <1fe64ae6f12eeda1c2aa59daea7f89e57e0e35a9.1424802755.git.s.strogin@partner.samsung.com>
 <87pp8qa1ab.fsf@linux.vnet.ibm.com>
In-reply-to: <87pp8qa1ab.fsf@linux.vnet.ibm.com>
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA02RW0iTYRzGeb/zpsOvpfGyIGEQUZCHTrxUSEIXXxdRoZF00qlLhU1la9KC
	TDYLnWaeStMhSzOaWs5pZiKU03lYKOpEU1FMMSwz8zzSZn7tIu+e//P8eJ6LP4OLWwkJk5B4
	W65KlCmklJD45O4cPPz5lzs8KH1YhL6U5dPIWFtDoem5MgItmWco9FW3AtDTIguJzFl6Cr3L
	LKZRZt4LGjmbjRSaqNki0ev2cRqZOtNJ9HJ1gUbjDjuFctbbaFRQKkFr3UYcVbSP4Wio6TGG
	nD+2aPSk2EWjbksPiSx64RnIOXMeYdz7knGaK814RnLWqkyKsy7l05xhfhDjuoo3CG7SVk9w
	bza/Y9zizCjBtf5swbichirAvapep7ll6z7OUPebvOhzVXg6Vq5ISJGrAkOihPFZLk1yl/hO
	gW2TTAN2HwMQMJA9BvueV9MevQf2TdRSBiBkxGwlgF3NA8BzLALY0pJL8ZSIPQLXHDaC1wS7
	H45NVgJeU9tNHX1F25ph/NgIOOYUePBd0FUw8Q/3ZRUwW5+N8504O0XCPEchzge72RuwaNmG
	ecY+Aviwc5TkAwEbBIsbjBhfirMHYGGhkrdx1h/W18zjuYAt2bFR8p8q2UGZAF4F/OSamGR1
	dJwyOEAtU6o1iXEBMUlKK/C8faUJVHSctAGWAVJv0cg1d7iYlKWotUobgAwu9RVp7NuWKFam
	vStXJUWqNAq52gYwRiBJAyFzUxfuXwpPFWWnngdzUZTBdOq4rihj4ES1rnrafP1b/5VNS3DW
	yKpb4OV3uao3756v2csuigiNu9l2NtLSq4+WrHPa/lDx0b3XTQd7ghrr5t96N9aOxsxqA9NN
	woIGbZhr9da5Ef+hhTClbsPxoZyuLJc+GK7MSZtV/ik0LkkJdbws+BCuUsv+AgZM22nUAgAA
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Aneesh,

On 03/03/15 12:16, Aneesh Kumar K.V wrote:
> Stefan Strogin <s.strogin@partner.samsung.com> writes:
> 
>> When CONFIG_CMA_BUFFER_LIST is configured a file is added to debugfs:
>> /sys/kernel/debug/cma/cma-<N>/buffers contains a list of currently allocated
>> CMA buffers for each CMA region (N stands for number of CMA region).
>>
>> Format is:
>> <base_phys_addr> - <end_phys_addr> (<size> kB), allocated by <PID> (<comm>)
>>
>> 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-<N>/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)
>>  [<c1142c4b>] cma_alloc+0x1bb/0x200
>>  [<c143d28a>] dma_alloc_from_contiguous+0x3a/0x40
>>  [<c10079d9>] dma_generic_alloc_coherent+0x89/0x160
>>  [<c14456ce>] dmam_alloc_coherent+0xbe/0x100
>>  [<c1487312>] ahci_port_start+0xe2/0x210
>>  [<c146e0e0>] ata_host_start.part.28+0xc0/0x1a0
>>  [<c1473650>] ata_host_activate+0xd0/0x110
>>  [<c14881bf>] ahci_host_activate+0x3f/0x170
>>  [<c14854e4>] ahci_init_one+0x764/0xab0
>>  [<c12e415f>] pci_device_probe+0x6f/0xd0
>>  [<c14378a8>] driver_probe_device+0x68/0x210
>>  [<c1437b09>] __driver_attach+0x79/0x80
>>  [<c1435eef>] bus_for_each_dev+0x4f/0x80
>>  [<c143749e>] driver_attach+0x1e/0x20
>>  [<c1437197>] bus_add_driver+0x157/0x200
>>  [<c14381bd>] 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 <command>' 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. 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.