On Mon, 11 May 2015, Vlastimil Babka wrote: > Khugepaged tries to preallocate a hugepage before scanning for THP collapse > candidates. If the preallocation fails, scanning is not attempted. This makes > sense, but it is only restricted to !NUMA configurations, where it does not > need to predict on which node to preallocate. > > Besides the !NUMA restriction, the preallocated page may also end up being > unused and put back when no collapse candidate is found. I have observed the > thp_collapse_alloc vmstat counter to have 3+ times the value of the counter > of actually collapsed pages in /sys/.../khugepaged/pages_collapsed. On the > other hand, the periodic hugepage allocation attempts involving sync > compaction can be beneficial for the antifragmentation mechanism, but that's > however harder to evaluate. > > The following patch will introduce per-node THP availability tracking, which > has more benefits than current preallocation and is applicable to CONFIG_NUMA. > We can therefore remove the preallocation, which also allows a cleanup of the > functions involved in khugepaged allocations. Another small benefit of the > patch is that NUMA configs can now reuse an allocated hugepage for another > collapse attempt, if the previous one was for the same node and failed. > > Signed-off-by: Vlastimil Babka <[email protected]>
I think this is fine if the rest of the series is adopted, and I understand how the removal and cleanup is easier when done first before the following patches. I think you can unify alloc_hugepage_node() for both NUMA and !NUMA configs and inline it in khugepaged_alloc_page(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
