On Fri, 20 Aug 2010 10:10:45 +0200
**UNKNOWN CHARSET** [off-list ref] wrote:

quoted

I wrote "similar to the existing API', not "reuse the existing API".

Yes, but I don't really know what you have in mind.  CMA is similar to various
APIs in various ways: it's similar to any allocator since it takes
size in bytes,

why don't take gfp_t flags?

Something like dev_alloc_page is more appropriate name?

Or something similar to dmapool API (mm/dmapool.c) might work
better. The purpose of dmapool API is creating a pool for consistent
memory per device. It's similar to yours, creating a pool for
contiguous memory per device(s)?

it's similar to coherent since it takes device, it's similar to bootmem/memblock/etc
since it takes alignment.

I don't think that bootmem/memblock matters here since it's not the
API for drivers.

quoted

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 +++++++++++++++

Ah, sorry.  I misunderstood you.  I thought you were replying to both 2. and 3.
above.

If we only take allocating algorithm then you're right.  Reusing existing one
should not increase the patch size plus it would be probably a better solution.

No matter, I would rather first work and core CMA without worrying about reusing
kmalloc()/coherent/etc. code especially since providing a plugable allocator API
integration with existing allocating algorithms can be made later on.  To put it
short I want first to make it work and then improve it.

I'm not sure that's how a new feature is merged.