Message-ID: <54A34A1C.90603@lge.com>
Date:	Wed, 31 Dec 2014 09:58:04 +0900
From:	Gioh Kim <gioh.kim@....com>
To:	Minchan Kim <minchan@...nel.org>,
	Laura Abbott <lauraa@...eaurora.org>
CC:	"Stefan I. Strogin" <s.strogin@...tner.samsung.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	aneesh.kumar@...ux.vnet.ibm.com,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Dmitry Safonov <d.safonov@...tner.samsung.com>,
	Pintu Kumar <pintu.k@...sung.com>,
	Weijie Yang <weijie.yang@...sung.com>,
	SeongJae Park <sj38.park@...il.com>,
	Hui Zhu <zhuhui@...omi.com>,
	Dyasly Sergey <s.dyasly@...sung.com>,
	Vyacheslav Tyrtov <v.tyrtov@...sung.com>, rostedt@...dmis.org,
	namhyung@...nel.org
Subject: Re: [PATCH 0/3] mm: cma: /proc/cmainfo



2014-12-30 오후 1:47에 Minchan Kim 이(가) 쓴 글:
> On Mon, Dec 29, 2014 at 11:52:58AM -0800, Laura Abbott wrote:
>> On 12/28/2014 6:36 PM, Minchan Kim wrote:
>>> Hello,
>>>
>>> On Fri, Dec 26, 2014 at 05:39:01PM +0300, Stefan I. Strogin wrote:
>>>> Hello all,
>>>>
>>>> Here is a patch set that adds /proc/cmainfo.
>>>>
>>>> When compiled with CONFIG_CMA_DEBUG /proc/cmainfo will contain information
>>>> about about total, used, maximum free contiguous chunk and all currently
>>>> allocated contiguous buffers in CMA regions. The information about allocated
>>>> CMA buffers includes pid, comm, allocation latency and stacktrace at the
>>>> moment of allocation.
>>>
>>> It just says what you are doing but you didn't say why we need it.
>>> I can guess but clear description(ie, the problem what you want to
>>> solve with this patchset) would help others to review, for instance,
>>> why we need latency, why we need callstack, why we need new wheel
>>> rather than ftrace and so on.
>>>
>>> Thanks.
>>>
>>
>>
>> I've been meaning to write something like this for a while so I'm
>> happy to see an attempt made to fix this. I can't speak for the
>> author's reasons for wanting this information but there are
>> several reasons why I was thinking of something similar.
>>
>> The most common bug reports seen internally on CMA are 1) CMA is
>> too slow and 2) CMA failed to allocate memory. For #1, not all
>> allocations may be slow so it's useful to be able to keep track
>> of which allocations are taking too long. For #2, migration
>
> Then, I don't think we could keep all of allocations. What we need
> is only slow allocations. I hope we can do that with ftrace.
>
> ex)
>
> # cd /sys/kernel/debug/tracing
> # echo 1 > options/stacktrace
> # echo cam_alloc > set_ftrace_filter
> # echo your_threshold > tracing_thresh
>
> I know it doesn't work now but I think it's more flexible
> and general way to handle such issues(ie, latency of some functions).
> So, I hope we could enhance ftrace rather than new wheel.
> Ccing ftrace people.

For CMA performance test or code flow check, ftrace is better.

ex)
echo cma_alloc > /sys/kernel/debug/tracing/set_graph_function
echo function_graph > /sys/kernel/debug/tracing/current_tracer
echo funcgraph-proc > /sys/kernel/debug/tracing/trace_options
echo nosleep-time > /sys/kernel/debug/tracing/trace_options
echo funcgraph-tail > /sys/kernel/debug/tracing/trace_options
echo 1 > /sys/kernel/debug/tracing/tracing_on

This can trace every cam_alloc and allocation time.
I think ftrace is better to debug latency.
If a buffer had allocated and had peak latency and freed,
we can check it.

But ftrace doesn't provide current status how many buffers we have and what address it is.
So I think debugging information is useful.



>
> Futhermore, if we really need to have such information, we need more data
> (ex, how many of pages were migrated out, how many pages were dropped
> without migrated, how many pages were written back, how many pages were
> retried with the page lock and so on).
> In this case, event trace would be better.
>
>
>> failure is fairly common but it's still important to rule out
>> a memory leak from a dma client. Seeing all the allocations is
>> also very useful for memory tuning (e.g. how big does the CMA
>> region need to be, which clients are actually allocating memory).
>
> Memory leak is really general problem and could we handle it with
> page_owner?
>
>>
>> ftrace is certainly usable for tracing CMA allocation callers and
>> latency. ftrace is still only a fixed size buffer though so it's
>> possible for information to be lost if other logging is enabled.
>
> Sorry, I don't get with only above reasons why we need this. :(
>
>> For most of the CMA use cases, there is a very high cost if the
>> proper debugging information is not available so the more that
>> can be guaranteed the better.
>>
>> It's also worth noting that the SLUB allocator has a sysfs
>> interface for showing allocation callers when CONFIG_SLUB_DEBUG
>> is enabled.
>>
>> Thanks,
>> Laura
>>
>> --
>> Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@...ck.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@...ck.org"> email@...ck.org </a>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists