Re: [PATCH v3] mm: compaction: handle incorrect Unmovable type pageblocks
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On 04/26/2012 12:47 PM, Mel Gorman wrote:
Instead of COMPACT_ASYNC_PARTIAL and COMPACT_ASYNC_FULL should we have COMPACT_ASYNC_MOVABLE and COMPACT_ASYNC_UNMOVABLE? The first pass from the page allocator (COMPACT_ASYNC_MOVABLE) would only consider MOVABLE blocks as migration targets. The second pass (COMPACT_ASYNC_UNMOVABLE) would examine UNMOVABLE blocks, rescue them and use what blocks it rescues as migration targets. The third pass (COMPACT_SYNC) would work as it does currently. kswapd would only ever use COMPACT_ASYNC_MOVABLE. That would avoid rescanning the movable blocks uselessly on the second pass but should still work for Bartlomiej's workload. What do you think?
This makes sense.
In other words, could it be better to always try to rescue the unmovable blocks?I do not think we should always scan within unmovable blocks on the first pass. I strongly suspect it would lead to excessive amounts of CPU time spent in mm/compaction.c.
Maybe my systems are not typical. I have not seen more than about 10% of the memory blocks marked as unmovable in my system. -- 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>