Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753870AbbBNHkk (ORCPT ); Sat, 14 Feb 2015 02:40:40 -0500 Received: from lgeamrelo02.lge.com ([156.147.1.126]:38724 "EHLO lgeamrelo02.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751473AbbBNHkj (ORCPT ); Sat, 14 Feb 2015 02:40:39 -0500 X-Original-SENDERIP: 10.178.37.108 X-Original-MAILFROM: gioh.kim@lge.com Message-ID: <54DEFBF4.40206@lge.com> Date: Sat, 14 Feb 2015 16:40:36 +0900 From: Gioh Kim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Joonsoo Kim , Stefan Strogin CC: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Marek Szyprowski , Michal Nazarewicz , aneesh.kumar@linux.vnet.ibm.com, Laurent Pinchart , Dmitry Safonov , Pintu Kumar , Weijie Yang , Laura Abbott , SeongJae Park , Hui Zhu , Minchan Kim , Dyasly Sergey , Vyacheslav Tyrtov , gregory.0xf0@gmail.com, sasha.levin@oracle.com, pavel@ucw.cz, stefan.strogin@gmail.com Subject: Re: [PATCH 0/4] mm: cma: add some debug information for CMA References: <20150213030308.GG6592@js1304-P5Q-DELUXE> In-Reply-To: <20150213030308.GG6592@js1304-P5Q-DELUXE> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2275 Lines: 54 2015-02-13 오후 12:03에 Joonsoo Kim 이(가) 쓴 글: > On Fri, Feb 13, 2015 at 01:15:40AM +0300, Stefan Strogin wrote: >> Hi all. >> >> Sorry for the long delay. Here is the second attempt to add some facility >> for debugging CMA (the first one was "mm: cma: add /proc/cmainfo" [1]). >> >> This patch set is based on v3.19 and Sasha Levin's patch set >> "mm: cma: debugfs access to CMA" [2]. >> It is also available on git: >> git://github.com/stefanstrogin/cmainfo -b cmainfo-v2 >> >> We want an interface to see a list of currently allocated CMA buffers and >> some useful information about them (like /proc/vmallocinfo but for physically >> contiguous buffers allocated with CMA). >> >> Here is an example use case when we need it. We want a big (megabytes) >> CMA buffer to be allocated in runtime in default CMA region. If someone >> already uses CMA then the big allocation can fail. If it happens then with >> such an interface we could find who used CMA at the moment of failure, who >> caused fragmentation (possibly ftrace also would be helpful here) and so on. > > Hello, > > So, I'm not sure that information about allocated CMA buffer is really > needed to solve your problem. You just want to know who uses default CMA > region and you can know it by adding tracepoint in your 4/4 patch. We > really need this custom allocation tracer? What can we do more with > this custom tracer to solve your problem? Could you more specific > about your problem and how to solve it by using this custom tracer? > >> >> These patches add some files to debugfs when CONFIG_CMA_DEBUGFS is enabled. > > If this tracer is justifiable, I think that making it conditional is > better than just enabling always on CONFIG_CMA_DEBUGFS. Some users > don't want to this feature although they enable CONFIG_CMA_DEBUGFS. > > Thanks. > Hello, Thanks for your work. It must be helpful to me. What about add another option to activate stack-trace? In my platform I know all devices using cma area, so I usually don't need stack-trace. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/