On 05/13/2016 04:15 PM, Michal Hocko wrote:
On Tue 10-05-16 09:36:02, Vlastimil Babka wrote:
- should_compact_retry() is only called when should_reclaim_retry() returns
false. This means that compaction priority cannot get increased as long
as reclaim makes sufficient progress. Theoretically, reclaim should stop
retrying for high-order allocations as long as the high-order page doesn't
exist but due to races, this may result in spurious retries when the
high-order page momentarily does exist.
This is intentional behavior and I would like to preserve it if it is
possible. For higher order pages should_reclaim_retry retries as long
as there are some eligible high order pages present which are just hidden
by the watermark check. So this is mostly to get us over watermarks to
start carrying about fragmentation. If we race there then nothing really
terrible should happen and we should eventually converge to a terminal
state.
Does this make sense to you?
Yeah it should work, my only worry was that this may get subtly wrong
(as experience shows us) and due to e.g. slightly different watermark
checks and/or a corner-case zone such as ZONE_DMA,
should_reclaim_retry() would keep returning true, even if reclaim
couldn't/wouldn't help anything. Then compaction would be needlessly
kept at ineffective priority.
Also my understanding of the initial compaction priorities is to lower
the latency if fragmentation is just light and there's enough memory.
Once we start struggling, I don't see much point in not switching to the
full compaction priority quickly.
--
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>