Re: [PATCH 0/4] mm: cma: add some debug information for CMA

From: Gioh Kim
Date: Sat Feb 14 2015 - 02:40:52 EST

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:// -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.


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 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@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at