On Mon, Aug 26, 2019 at 12:55 PM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > 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. > okay > > > 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). Okay Thanks michal, now it will easy to understand. > > > > > > > 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. > okay > > What is work of shrink_page_list() ? > > This is a core of the memory reclaim. It unmaps/frees pages and try to > free them. > okay > > 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. hahaha rocket science !!! I think linux memory management should be part of rocket science. > > -- > Michal Hocko > SUSE Labs
