On 09/30/2015 04:16 PM, Vitaly Wool wrote:
So what do you suggest instead? A fixed number, some other heuristic?
You have pushed several times now for the series to focus on the latency
of standard high-order allocations but again I will say that it is
outside
the scope of this series. If you want to take steps to reduce the latency
of ordinary high-order allocation requests that can sleep then it should
be a separate series.
I do believe https://lkml.org/lkml/2015/9/9/313 does a better job
Does a better job regarding what exactly? It does fix the CMA-specific
issue, but so does this patch - without affecting allocation fastpaths by
making them update another counter. But the issues discussed here are not
related to that CMA problem.
Let me disagree. Guaranteeing one suitable high-order page is not
enough, so the suggested patch does not work that well for me.
Existing broken watermark calculation doesn't work for me either, as
opposed to the one with my patch applied. Both solutions are related
to the CMA issue but one does make compaction work harder and cause
bigger latencies -- why do you think these are not related?
Well you didn't mention which issues you have with this patch. If you
did measure bigger latencies and more compaction work, please post the
numbers and details about the test.
--
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>