Re: How cma allocation works ?

[Michal Hocko]

On Fri 23-08-19 00:17:22, Pankaj Suryawanshi wrote:
> On Thu, Aug 22, 2019 at 6:32 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> >
> > On Wed 21-08-19 22:58:03, Pankaj Suryawanshi wrote:
> > > Hello,
> > >
> > > Hard time to understand cma allocation how differs from normal
> > > allocation ?
> >
> > The buddy allocator which is built for order-N sized allocations and it
> > is highly optimized because it used from really hot paths. The allocator
> > also involves memory reclaim to get memory when there is none
> > immediatelly available.
> >
> > CMA allocator operates on a pre reserved physical memory range(s) and
> > focuses on allocating areas that require physically contigous memory of
> > larger sizes. Very broadly speaking. LWN usually contains nice writeups
> > for many kernel internals. E.g. quick googling pointed to
> > https://lwn.net/Articles/486301/
> >
> > > I know theoretically how cma works.
> > >
> > > 1. How it reserved the memory (start pfn to end pfn) ? what is bitmap_*
> > > functions ?
> >
> > Not sure what you are asking here TBH
> I know it reserved memory at boot time from start pfn to end pfn, but when
> i am requesting memory from cma it has different bitmap_*() in cma_alloc()
> what they are ?
> because we pass pfn and pfn+count to alloc_contig_range and pfn is come
> from bitmap_*() function.
> lets say i have reserved 100MB cma memory at boot time (strart pfn to end
> pfn) and i am requesting allocation of 30MB from cma area then what is pfn
> passed to alloc_contig_range() it is same as start pfn or
> different.(calucaled by bitmap_*()) ?

I am not deeply familiar with the CMA implementation but from a very
brief look it seems that the bitmap simply denotes which portions of the
reserved area are used and therefore it is easy to find portions of the
requested size by scanning it.

> > Have you checked the code? It simply tries to reclaim and/or migrate
> > pages off the pfn range.
> >
> What is difference between migration, isolation and reclamation of pages ?

Isolation will set the migrate type to MIGRATE_ISOLATE, btw the comment
in the code I referred to says this:
 * Making page-allocation-type to be MIGRATE_ISOLATE means free pages in
 * the range will never be allocated. Any free pages and pages freed in the
 * future will not be allocated again. If specified range includes migrate types
 * other than MOVABLE or CMA, this will fail with -EBUSY. For isolating all
 * pages in the range finally, the caller have to free all pages in the range.
 * test_page_isolated() can be used for test it.

Reclaim part will simply drop all pages that are easily reclaimable
(e.g. a clean pagecache) and migration will move existing allocations to
a different physical location + update references to it from other data
structures (e.g. page tables to point to a new location).

> > > 5.what isolate_migratepages_range(), reclaim_clean_pages_from_list(),
> > >  migrate_pages() and shrink_page_list() is doing ?
> >
> > Again, have you checked the code/comments? What exactly is not clear?
> >
> Why again migrate_isolate_range() ?
> (reclaim_clean_pages_fron_list) if we are reclaiming only clean pages then
> pages will not contiguous ? we have only clean pages which are not
> contiguous ?

reclaim_clean_pages_from_list is a simple wrapper on top of shrink_page_list.
It simply takes clean page cache pages to reclaim it because that might
be less expensive than migrating that memory.

> What is work of shrink_page_list() ?

This is a core of the memory reclaim. It unmaps/frees pages and try to
free them.

> please explain all flow with taking
> one allocation for example let say reserved cma 100MB and then request
> allocation of 30MB then how all the flow/function will work ?

I would recommend to read the code carefully and following the git
history of the code is very helpful as well. This is not a rocket
science, really.
-- 
Michal Hocko
SUSE Labs