Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
mm: prevent MIGRATE_ISOLATE pages entering other free lists
It is observed that, during a CMA allocation, test_pages_isolated() fails sometimes. In low memory situations, this results in continuous failures of CMA allocations. When testing for isolation, test_pages_isolated finds that some pages are allocated, which were available on pcp list when start_isolate_page_range marked the pageblock as MIGRATE_ISOLATE. These pages, though marked as isolated in the respective pageblock, are moved to non-isolate freelists while being drained. This results in these pages being allocated from other paths while a contig allocation is in progress. In certain cases, these pages get allocated from the migrate_pages() of current alloc_contig_range() itself. In the function free_pcppages_bulk(), when a page is moved to buddy, the migrate list is picked based on page_private. In the case of CMA pages, which were on pcp list during start_isolate_page_range, page_private will point to MIGRATE_CMA, and the pageblock migrate type can be MIGRATE_ISOLATE. This results in these pages being moved to cma freelist, rather than isolate freelist, inside free_pcppages_bulk. This means they can get allocated. If cma pages are never allowed to enter pcp lists, we will not hit this issue. This is partly done by free_hot_cold_page(), where we prevent cma pages entering pcp. But cma pages can still get on pcp lists through rmqueue_bulk. Preventing cma pages enter pcp via rmqueue_bulk, can result in underutilization of CMA pages for non-contiguous allocations, as rmqueue_bulk is the frequent path for order 0 allocations. CRs-fixed:720761 Change-Id: I01b12e6455c75519f1dce5d31467123cb1eb54b7 Signed-off-by: Vinayak Menon <[email protected]> Reviewed-on: http://gerrit.mot.com/687990 Submit-Approved: Jira Key <[email protected]> Tested-by: Jira Key <[email protected]> Reviewed-by: Jeffrey Carlyle <[email protected]> Reviewed-by: Igor Kovalenko <[email protected]> Reviewed-by: Yi-Wei Zhao <[email protected]> SLTApproved: Connie Zhao <[email protected]>
- Loading branch information