On 11/19/2011 02:54 PM, Andrea Arcangeli wrote:
This reverts commit e0887c19b2daa140f20ca8104bdc5740f39dbb86. If reclaim runs with an high order allocation, it means compaction failed. That means something went wrong with compaction so we can't stop reclaim too. We can't assume it failed and was deferred only because of the too low watermarks in compaction_suitable, it may have failed for other reasons. Signed-off-by: Andrea Arcangeli<aarcange@xxxxxxxxxx>
NACK Reverting this can lead to the situation where every time we have an attempted THP allocation, we free 4MB more memory. This has led to systems with 1/4 to 1/3 of all memory free and pushed to swap, while the system continues with swapout activity. The thrashing this causes can be a factor 10 or worse performance penalty. Failing a THP allocation is merely a 10-20% performance penalty, which is not as much of an issue. We can move the threshold at which we skip pageout to be a little higher (to give compaction more space to work with), and even call shrink_slab when we skip other reclaiming (because slab cannot be moved by compaction), but whatever we do we do need to ensure that we never reclaim an unreasonable amount of memory and end up pushing the working set into swap. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>