Re: [PATCH/RFCv3 0/6] The Contiguous Memory Allocator framework

[FUJITA Tomonori]

On Fri, 20 Aug 2010 08:38:10 +0200
**UNKNOWN CHARSET** <m.nazarewicz@xxxxxxxxxxx> wrote:

> On Fri, 20 Aug 2010 05:12:50 +0200, FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> wrote:
> >> 1. Integration on API level meaning that some kind of existing API is used
> >>     instead of new cma_*() calls.  CMA adds notion of devices and memory
> >>     types which is new to all the other APIs (coherent has notion of devices
> >>     but that's not enough).  This basically means that no existing API can be
> >>     used for CMA.  On the other hand, removing notion of devices and memory
> >>     types would defeat the whole purpose of CMA thus destroying the solution
> >>     that CMA provides.
> >
> > You can create something similar to the existing API for memory
> > allocator.
> 
> That may be tricky.  cma_alloc() takes four parameters each of which is
> required for CMA.  No other existing set of API uses all those arguments.
> This means, CMA needs it's own, somehow unique API.  I don't quite see
> how the APIs may be unified or "made similar".  Of course, I'm gladly
> accepting suggestions.

Have you even tried to search 'blk_kmalloc' on google? I wrote
"similar to the existing API', not "reuse the existing API".


> >> 2. Reuse of memory pools meaning that memory reserved by CMA can then be
> >>     used by other allocation mechanisms.  This is of course possible.  For
> >>     instance coherent could easily be implemented as a wrapper to CMA.
> >>     This is doable and can be done in the future after CMA gets more
> >>     recognition.
> >>
> >> 3. Reuse of algorithms meaning that allocation algorithms used by other
> >>     allocators will be used with CMA regions.  This is doable as well and
> >>     can be done in the future.
> >
> > Well, why can't we do the above before the inclusion?
> 
> Because it's quite a bit of work and instead of diverting my attention I'd
> prefer to make CMA as good as possible and then integrate it with other
> subsystems.  Also, adding the integration would change the patch from being
> 4k lines to being like 40k lines.

4k to 40k? I'm not sure. But If I see something like the following, I
suspect that there is a better way to integrate this into the existing
infrastructure.

mm/cma-best-fit.c                   |  407 +++++++++++++++
--
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/