On 10/18/18 8:48 AM, Aaron Lu wrote: > 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 I'm not sure I understand. Why should it matter for merging if pages are adjacent on the unmerged_free_list? The buddy for merging is found the usual way, no? > 2 there are a lot of unmerged pages on unmerged_free_list. That will affect allocation latency, yeah. Still might be faster than direct compaction. And possible to do in GFP_ATOMIC context, unlike direct compaction. > 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. Note that anything based on daemons will seem like reducing latency for allocations, but if we delay merging and then later do it from a daemon, the overall zone lock times will be essentially the same, right? The reduced zone lock benefits only happen when the unmerged pages get reallocated. >> 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... In that case there should definitely be a direct merging possibility IMHO, even if only as a last resort before stealing from another pageblock.
