On 2 Feb 2018, at 17:47, Mel Gorman wrote: > On Fri, Feb 02, 2018 at 02:16:39PM +0000, Robert Harris wrote: >> I was planning to annotate the opaque calculation in >> __fragmentation_index() but on closer inspection I think there may be a >> bug. I could use some feedback. A belated thank you for the reply. > It's intentional but could be fixed to give a real bound of 0 to 1 instead > of half the range as it currently give. The sysctl_extfrag_threshold should > also be adjusted at that time. After that, the real work is determining > if it's safe to strike a balance between reclaim/compaction that avoids > unnecessary compaction while not being too aggressive about reclaim or > having kswapd enter a runaway loop with a reintroduction of the "kswapd > stuck at 100% CPU time" problems. In my (incomplete) view, striking the balance is a case of determining the cost of memory regeneration through compaction versus reclaim and choosing the cheaper. I'm reasonably confident that this could be achieved for compaction, which is why the calculation in __fragmentation_index() caught my eye in the first place, but reclaim/swapping is probably significantly harder to quantify. Similarly, a cost function for allocation failure is also necessary but not obvious. All of the above is just a nebulous plan for now; in the meantime, I'll change __fragmentation_index() and the threshold as you suggest. Robert Harris -- 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>
