Re: [PATCHv8 00/12] Contiguous Memory Allocator

[Kyungmin Park <kmpark@infradead.org>]

Hi Andrew,

any comments? what's the next step to merge it for 2.6.38 kernel. we
want to use this feature at mainline kernel.

Any idea and comments are welcome.

Thank you,
Kyungmin Park

On Thu, Dec 16, 2010 at 5:34 AM, Michal Nazarewicz
<m.nazarewicz@samsung.com> wrote:
> Hello everyone,
>
> This is yet another version of CMA this time stripped from a lot of
> code and with working migration implementation.
>
>   The Contiguous Memory Allocator (CMA) makes it possible for
>   device drivers to allocate big contiguous chunks of memory after
>   the system has booted.
>
> For more information see 7th patch in the set.
>
>
> This version fixes some things Kamezawa suggested plus it separates
> code that uses MIGRATE_CMA from the rest of the code.  This I hope
> will help to grasp the overall idea of CMA.
>
>
> The current version is just an allocator that handles allocation of
> contiguous memory blocks.  The difference between this patchset and
> Kamezawa's alloc_contig_pages() are:
>
> 1. alloc_contig_pages() requires MAX_ORDER alignment of allocations
>   which may be unsuitable for embeded systems where a few MiBs are
>   required.
>
>   Lack of the requirement on the alignment means that several threads
>   might try to access the same pageblock/page.  To prevent this from
>   happening CMA uses a mutex so that only one cm_alloc()/cm_free()
>   function may run at one point.
>
> 2. CMA may use its own migratetype (MIGRATE_CMA) which behaves
>   similarly to ZONE_MOVABLE but can be put in arbitrary places.
>
>   This is required for us since we need to define two disjoint memory
>   ranges inside system RAM.  (ie. in two memory banks (do not confuse
>   with nodes)).
>
> 3. alloc_contig_pages() scans memory in search for range that could be
>   migrated.  CMA on the other hand maintains its own allocator to
>   decide where to allocate memory for device drivers and then tries
>   to migrate pages from that part if needed.  This is not strictly
>   required but I somehow feel it might be faster.
>
>
> Links to previous versions of the patchset:
> v7: <http://article.gmane.org/gmane.linux.kernel.mm/55626>
> v6: <http://article.gmane.org/gmane.linux.kernel.mm/55626>
> v5: (intentionally left out as CMA v5 was identical to CMA v4)
> v4: <http://article.gmane.org/gmane.linux.kernel.mm/52010>
> v3: <http://article.gmane.org/gmane.linux.kernel.mm/51573>
> v2: <http://article.gmane.org/gmane.linux.kernel.mm/50986>
> v1: <http://article.gmane.org/gmane.linux.kernel.mm/50669>
>
>
> Changelog:
>
> v8: 1. The alloc_contig_range() function has now been separated from
>       CMA and put in page_allocator.c.  This function tries to
>       migrate all LRU pages in specified range and then allocate the
>       range using alloc_contig_freed_pages().
>
>    2. Support for MIGRATE_CMA has been separated from the CMA code.
>       I have not tested if CMA works with ZONE_MOVABLE but I see no
>       reasons why it shouldn't.
>
>    3. I have added a @private argument when creating CMA contexts so
>       that one can reserve memory and not share it with the rest of
>       the system.  This way, CMA acts only as allocation algorithm.
>
> v7: 1. A lot of functionality that handled driver->allocator_context
>       mapping has been removed from the patchset.  This is not to say
>       that this code is not needed, it's just not worth posting
>       everything in one patchset.
>
>       Currently, CMA is "just" an allocator.  It uses it's own
>       migratetype (MIGRATE_CMA) for defining ranges of pageblokcs
>       which behave just like ZONE_MOVABLE but dispite the latter can
>       be put in arbitrary places.
>
>    2. The migration code that was introduced in the previous version
>       actually started working.
>
>
> v6: 1. Most importantly, v6 introduces support for memory migration.
>       The implementation is not yet complete though.
>
>       Migration support means that when CMA is not using memory
>       reserved for it, page allocator can allocate pages from it.
>       When CMA wants to use the memory, the pages have to be moved
>       and/or evicted as to make room for CMA.
>
>       To make it possible it must be guaranteed that only movable and
>       reclaimable pages are allocated in CMA controlled regions.
>       This is done by introducing a MIGRATE_CMA migrate type that
>       guarantees exactly that.
>
>       Some of the migration code is "borrowed" from Kamezawa
>       Hiroyuki's alloc_contig_pages() implementation.  The main
>       difference is that thanks to MIGRATE_CMA migrate type CMA
>       assumes that memory controlled by CMA are is always movable or
>       reclaimable so that it makes allocation decisions regardless of
>       the whether some pages are actually allocated and migrates them
>       if needed.
>
>       The most interesting patches from the patchset that implement
>       the functionality are:
>
>         09/13: mm: alloc_contig_free_pages() added
>         10/13: mm: MIGRATE_CMA migration type added
>         11/13: mm: MIGRATE_CMA isolation functions added
>         12/13: mm: cma: Migration support added [wip]
>
>       Currently, kernel panics in some situations which I am trying
>       to investigate.
>
>    2. cma_pin() and cma_unpin() functions has been added (after
>       a conversation with Johan Mossberg).  The idea is that whenever
>       hardware does not use the memory (no transaction is on) the
>       chunk can be moved around.  This would allow defragmentation to
>       be implemented if desired.  No defragmentation algorithm is
>       provided at this time.
>
>    3. Sysfs support has been replaced with debugfs.  I always felt
>       unsure about the sysfs interface and when Greg KH pointed it
>       out I finally got to rewrite it to debugfs.
>
>
> v5: (intentionally left out as CMA v5 was identical to CMA v4)
>
>
> v4: 1. The "asterisk" flag has been removed in favour of requiring
>       that platform will provide a "*=<regions>" rule in the map
>       attribute.
>
>    2. The terminology has been changed slightly renaming "kind" to
>       "type" of memory.  In the previous revisions, the documentation
>       indicated that device drivers define memory kinds and now,
>
> v3: 1. The command line parameters have been removed (and moved to
>       a separate patch, the fourth one).  As a consequence, the
>       cma_set_defaults() function has been changed -- it no longer
>       accepts a string with list of regions but an array of regions