Re: [PATCH v3 4/7] mm/compaction: update defer counter when allocation is expected to succeed

From: Vlastimil Babka
Date: Fri Dec 04 2015 - 11:52:28 EST


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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/