Date:	Tue, 21 Jul 2015 11:03:58 +0200
From:	Vlastimil Babka <vbabka@...e.cz>
To:	David Rientjes <rientjes@...gle.com>
CC:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Hugh Dickins <hughd@...gle.com>,
	Andrea Arcangeli <aarcange@...hat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
	Joonsoo Kim <iamjoonsoo.kim@....com>
Subject: Re: [RFC 1/4] mm, compaction: introduce kcompactd

On 07/09/2015 11:53 PM, David Rientjes wrote:
> On Thu, 2 Jul 2015, Vlastimil Babka wrote:
>
>> Memory compaction can be currently performed in several contexts:
>>
>> - kswapd balancing a zone after a high-order allocation failure
>> - direct compaction to satisfy a high-order allocation, including THP page
>>    fault attemps
>> - khugepaged trying to collapse a hugepage
>> - manually from /proc
>>
>> The purpose of compaction is two-fold. The obvious purpose is to satisfy a
>> (pending or future) high-order allocation, and is easy to evaluate. The other
>> purpose is to keep overal memory fragmentation low and help the
>> anti-fragmentation mechanism. The success wrt the latter purpose is more
>> difficult to evaluate.
>>
>> The current situation wrt the purposes has a few drawbacks:
>>
>> - compaction is invoked only when a high-order page or hugepage is not
>>    available (or manually). This might be too late for the purposes of keeping
>>    memory fragmentation low.
>> - direct compaction increases latency of allocations. Again, it would be
>>    better if compaction was performed asynchronously to keep fragmentation low,
>>    before the allocation itself comes.
>> - (a special case of the previous) the cost of compaction during THP page
>>    faults can easily offset the benefits of THP.
>>
>> To improve the situation, we need an equivalent of kswapd, but for compaction.
>> E.g. a background thread which responds to fragmentation and the need for
>> high-order allocations (including hugepages) somewhat proactively.
>>
>> One possibility is to extend the responsibilities of kswapd, which could
>> however complicate its design too much. It should be better to let kswapd
>> handle reclaim, as order-0 allocations are often more critical than high-order
>> ones.
>>
>> Another possibility is to extend khugepaged, but this kthread is a single
>> instance and tied to THP configs.
>>
>> This patch goes with the option of a new set of per-node kthreads called
>> kcompactd, and lays the foundations. The lifecycle mimics kswapd kthreads.
>>
>> The work loop of kcompactd currently mimics an pageblock-order direct
>> compaction attempt each 15 seconds. This might not be enough to keep
>> fragmentation low, and needs evaluation.
>>
>> When there's not enough free memory for compaction, kswapd is woken up for
>> reclaim only (not compaction/reclaim).
>>
>> Further patches will add the ability to wake up kcompactd on demand in special
>> situations such as when hugepages are not available, or when a fragmentation
>> event occured.
>>
>
> Thanks for looking at this again.
>
> The code is certainly clean and the responsibilities vs kswapd and
> khugepaged are clearly defined, but I'm not sure how receptive others
> would be of another per-node kthread.

We'll hopefully see...

> Khugepaged benefits from the periodic memory compaction being done
> immediately before it attempts to compact memory, and that may be lost
> with a de-coupled approach like this.

That could be helped with waking up khugepaged after kcompactd is 
successful in making a hugepage available. Also in your rfc you propose 
the compaction period to be 15 minutes, while khugepaged wakes up each 
10 (or 30) seconds by default for the scanning and collapsing, so only 
fraction of the work is attempted right after the compaction anyway?

> Initially, I suggested implementing this inside khugepaged for that
> purpose, and the full compaction could be done on the next
> scan_sleep_millisecs wakeup before allocating a hugepage and when
> kcompactd_sleep_millisecs would have expired.  So the true period between
> memory compaction events could actually be
> kcompactd_sleep_millisecs - scan_sleep_millisecs.
>
> You bring up an interesting point, though, about non-hugepage uses of
> memory compaction and its effect on keeping fragmentation low.  I'm not
> sure of any reports of that actually being an issue in the wild?

Hm reports of even not-so-high-order allocation failures occur from time 
to time. Some might be from atomic context, but some are because 
compaction just can't help due to the unmovable fragmentation. That's 
mostly a guess, since such detailed information isn't there, but I think 
Joonsoo did some experiments that confirmed this.

Also effects on the fragmentation are evaluated when making changes to 
compaction, see e.g. http://marc.info/?l=linux-mm&m=143634369227134&w=2
In the past it has prevented changes that would improve latency of 
direct compaction. They might be possible if there was a reliable source 
of more thorough periodic compaction to counter the not-so-thorough 
direct compaction.

> I know that the networking layer has done work recently to reduce page
> allocator latency for high-order allocations that can easily fallback to
> order-0 memory: see commit fb05e7a89f50 ("net: don't wait for order-3 page
> allocation").

Yep.

> The slub allocator does try to allocate its high-order memory with
> __GFP_WAIT before falling back to lower orders if possible.  I would think
> that this would be the greatest sign of on-demand memory compaction being
> a problem, especially since CONFIG_SLUB is the default, but I haven't seen
> such reports.

Hm it's true I don't remember such report in the slub context.

> So I'm inclined to think that the current trouble spot for memory
> compaction is thp allocations.  I may live to find differently :)

Yeah it's the most troublesome one, but I wouldn't discount the others.

> How would you feel about implementing this as part of the khugepaged loop
> before allocating a hugepage and scanning memory?

Yeah that's what the previous version did:

http://thread.gmane.org/gmane.linux.kernel.mm/132522

But I found it increasingly clumsy and something that should not depend 
on CONFIG_THP only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists