On 12/03/2015 08:11 AM, Joonsoo Kim wrote:
It's rather strange that compact_considered and compact_defer_shift aren't updated but compact_order_failed is updated when allocation is expected to succeed. Regardless actual allocation success, deferring for current order will be disabled so it doesn't result in much difference to compaction behaviour.
The difference is that if the defer reset was wrong, the next compaction attempt that fails would resume the deferred counters?
Moreover, in the past, there is a gap between expectation for allocation succeess in compaction and actual success in page allocator. But, now, this gap would be diminished due to providing classzone_idx and alloc_flags to watermark check in compaction and changed watermark check criteria for high-order allocation. Therfore, it's not a big problem to update defer counter when allocation is expected to succeed. This change will help to simplify defer logic.
I guess that's true. But at least some experiment would be better.
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx> --- include/linux/compaction.h | 2 -- mm/compaction.c | 27 ++++++++------------------- mm/page_alloc.c | 1 - 3 files changed, 8 insertions(+), 22 deletions(-)
...
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 7002c66..f3605fd 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2815,7 +2815,6 @@ __alloc_pages_direct_compact(gfp_t gfp_mask, unsigned int order, struct zone *zone = page_zone(page); zone->compact_blockskip_flush = false;
While we are here, I wonder if this is useful at all? compact_blockskip_flush is set true when scanners meet. That typically means the compaction wasn't successful. Rarely it can be, but I doubt this will make much difference, so we could remove this line as well.
- compaction_defer_reset(zone, order, true); count_vm_event(COMPACTSUCCESS); return page; }
-- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>