On Wed, Sep 30, 2015 at 04:43:00PM +0200, Vlastimil Babka wrote: > >>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. > And very broadly watch out for decisions that force more reclaim/compaction to potentially reduce latency in the future. It's trading definite overhead now combined with potential reclaim of hot pages to reduce a *possible* high-order allocation request in the future. It's why I think a series that keeps more high-order pages free to reduce future high-order allocation latency needs to be treated with care. -- Mel Gorman SUSE Labs -- 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>