On Wed, Oct 17, 2018 at 07:03:30PM +0200, Vlastimil Babka wrote: > On 10/17/18 3:58 PM, Mel Gorman wrote: > > Again, as compaction is not guaranteed to find the pageblocks, it would > > be important to consider whether a) that matters or b) find an > > alternative way of keeping unmerged buddies on separate lists so they > > can be quickly discovered when a high-order allocation fails. > > Agree, unmerged buddies could be on separate freelist from regular > order-0 freelist. That list could be also preferred to allocations > before the regular one. Then one could e.g. try "direct merging" via > this list when compaction fails, or prefer direct merging to compaction > for non-costly-order allocations, do direct merging when allocation > context doesn't even allow compaction (atomic etc). One concern regarding "direct merging" these unmerged pages via this separate freelist(let's call it unmerged_free_list) is: adjacent unmerged pages on the unmerged_free_list could be far away from each other regarding their physical positions, so during the process of merging them, the needed high order page may not be able to be formed in a short time. Actually, the time could be unbound in a bad condition when: 1 unmerged pages adjacent on the unmerged_free_list happen to be far away from each other regarding their physical positions; and 2 there are a lot of unmerged pages on unmerged_free_list. That's the reason I hooked the merging of unmerged pages in compaction when isolate_migratepages_block() is scanning every page of a pageblock in PFN order. OTOH, if there is a kernel thread trying to reduce fragmentation by doing merges for these unmerged pages, I think it's perfect fine to let it iterate all unmerged pages of that list and do_merge() for all of them. So what about this: if kcompactd is running, let it handle these unmerged pages on the list and after that, do its usual job of compaction. If direct compaction is running, do not handle unmerged pages on that list but rely on isolate_migratepages_block() to do the merging as is done in this patchset. This of course has the effect of tying compaction with 'lazy merging'. If it is not desirable, what about creating a new kernel thread to do the merging of unmerged pages on the list while keeping the behaviour of isolate_migratepages_block() in this patchset to improve compaction success rate. > Also I would definitely consider always merging pages freed to > non-MOVABLE pageblocks. We really don't want to increase the > fragmentation in those. However that means it probably won't help the > netperf case? Yes, that would be unfortunate for all in-kernel users of page allocator...
