On Thu, Apr 26, 2012 at 02:52:56PM -0400, Rik van Riel 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. I see even less than 10% on my systems but I do not consider them to be typical and there will be systems where there are more unmovable pageblocks for whatever reason (lots of page table pages, anon_vmas and vmas for example). Hence I'd rather not assume that the number is typically low. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>