Hello. Actually this question is about kernel 3.10, but as i can see the situation didn't change in future versions. I would like to mention 2 places in the code: 1.) First one is an internals of buddy allocator subsystem function __rmqueue As i can see, kernel tries to allocate smallest suitable free block for given order and migratetype here __rmqueue_smallest. If it fails, then it could try other migration types here __rmqueue_fallback. The suitable migration types are in fallback list. For example, if we have MIGRATE_UNMOVABLE allocation, we can try: [MIGRATE_UNMOVABLE] = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE, MIGRATE_RESERVE} but as i can see we can't try MIGRATE_CMA free blocks. 2.) Now let's consider compaction_suitable function. This one is used in compact_zone, to check if the compaction is suitable. This function uses fill_contig_page_info, where number of suitable blocks for current order allocation is calculated like: 570 /* Count number of free blocks */ 571 blocks = zone->free_area[order].nr_free; 572 info->free_blocks_total += blocks; 573 574 /* Count free base pages */ 575 info->free_pages += blocks << order; 576 577 /* Count the suitable free blocks */ 578 if (order >= suitable_order) 579 info->free_blocks_suitable += blocks << 580 (order - suitable_order); So as i can see, zone->free_area[order].nr_free includes all MIGRATE_TYPES for given order. But if we allocate unmovable blocks, in fact we can't use free blocks with MIGRATE_CMA. As i think this could lead to the fact, that on slowpath __alloc_pages_direct_compact wouldn't invoke compaction, because it will think that we have suitable blocks for current order allocation, but in fact we haven't. Please, could you explain is this a problem, or i just don't understand some logic behind this? Thank you.