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.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
