On 12/03/2015 08:11 AM, Joonsoo Kim wrote:
Compaction deferring effectively reduces compaction overhead if compaction success isn't expected. But, it is implemented that skipping a number of compaction requests until compaction is re-enabled. Due to this implementation, unfortunate compaction requestor will get whole compaction overhead unlike others have zero overhead. And, after deferring start to work, even if compaction success possibility is restored, we should skip to compaction in some number of times. This patch try to solve above problem by using compaction limit. Instead of imposing compaction overhead to one unfortunate requestor, compaction limit distributes overhead to all compaction requestors. All requestors have a chance to migrate some amount of pages and after limit is exhausted compaction will be stopped. This will fairly distributes overhead to all compaction requestors. And, because we don't defer compaction request, someone will succeed to compact as soon as possible if compaction success possiblility is restored. Following is whole workflow enabled by this change. - if sync compaction fails, compact_order_failed is set to current order - if it fails again, compact_defer_shift is adjusted - with positive compact_defer_shift, migration_scan_limit is assigned and compaction limit is activated - if compaction limit is activated, compaction would be stopped when migration_scan_limit is exhausted - when success, compact_defer_shift and compact_order_failed is reset and compaction limit is deactivated - compact_defer_shift can be grown up to COMPACT_MAX_DEFER_SHIFT Most of changes are mechanical ones to remove compact_considered which is not needed now. Note that, after restart, compact_defer_shift is subtracted by 1 to avoid invoking __reset_isolation_suitable() repeatedly. I tested this patch on my compaction benchmark and found that high-order allocation latency is evenly distributed and there is no latency spike in the situation where compaction success isn't possible. Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
Looks fine overal, looking forward to next version :) (due to changes expected in preceding patches, I didn't review the code fully now).
-- 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>