On Fri, Jun 26, 2015 at 11:07:47AM +0900, Joonsoo Kim wrote: > >> > The long-term success rate of fragmentation avoidance depends on > >> > minimsing the number of UNMOVABLE allocation requests that use a > >> > pageblock belonging to another migratetype. Once such a fallback occurs, > >> > that pageblock potentially can never be used for a THP allocation again. > >> > > >> > Lets say there is an unmovable pageblock with 500 free pages in it. If > >> > the freepage scanner uses that pageblock and allocates all 500 free > >> > pages then the next unmovable allocation request needs a new pageblock. > >> > If one is not completely free then it will fallback to using a > >> > RECLAIMABLE or MOVABLE pageblock forever contaminating it. > >> > >> Yes, I can imagine that situation. But, as I said above, we already use > >> non-movable pageblock for migration scanner. While unmovable > >> pageblock with 500 free pages fills, some other unmovable pageblock > >> with some movable pages will be emptied. Number of freepage > >> on non-movable would be maintained so fallback doesn't happen. > >> > >> Anyway, it is better to investigate this effect. I will do it and attach > >> result on next submission. > >> > > > > Lets say we have X unmovable pageblocks and Y pageblocks overall. If the > > migration scanner takes movable pages from X then there is more space for > > unmovable allocations without having to increase X -- this is good. If > > the free scanner uses the X pageblocks as targets then they can fill. The > > next unmovable allocation then falls back to another pageblock and we > > either have X+1 unmovable pageblocks (full steal) or a mixed pageblock > > (partial steal) that cannot be used for THP. Do this enough times and > > X == Y and all THP allocations fail. > > This was similar with my understanding but different conclusion. > > As number of unmovable pageblocks, X, which is filled by movable pages > due to this compaction change increases, reclaimed/migrated out pages > from them also increase. There is no guarantee of that, it's timing sensitive and the kernel sepends more time copying data in/out of the same pageblocks which is wasteful. > And, then, further unmovable allocation request > will use this free space and eventually these pageblocks are totally filled > by unmovable allocation. Therefore, I guess, in the long-term, increasing X > is saturated and X == Y will not happen. > The whole reason we avoid migrating to unmovable blocks is because it did happen and quite quickly. Do not use unmovable blocks as migration targets. If high-order kernel allocations are required then some reclaim is necessary for compaction to work with. -- 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/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>