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

[Gioh Kim]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/