Re: [RFC v3 1/2] mm, compaction: introduce kcompactd
From: Vlastimil Babka
Date: Mon Aug 10 2015 - 05:44:23 EST
On 08/09/2015 05:37 PM, PINTU KUMAR wrote:
Waking up of the kcompactd threads is also tied to kswapd activity and follows
- we don't want to affect any fastpaths, so wake up kcompactd only from the
slowpath, as it's done for kswapd
- if kswapd is doing reclaim, it's more important than compaction, so
invoke kcompactd until kswapd goes to sleep
- the target order used for kswapd is passed to kcompactd
The kswapd compact/reclaim loop for high-order pages is left alone for now
and precedes kcompactd wakeup, but this might be revisited later.
kcompactd, will be really nice thing to have, but I oppose calling it from kswapd.
Because, just after kswapd, we already have direct_compact.
Just to be clear, here you mean that kswapd already does the
So it may end up in doing compaction 2 times.
The compact/reclaim loop might already do multiple iterations. The point
is, kswapd will terminate the loop as soon as single page of desired
order becomes available. Kcompactd is meant to go beyond that.
And having kcompactd run in parallel with kswapd's reclaim looks like
nonsense to me, so I don't see other way than have kswapd wake up
kcompactd when it's finished.
Or, is it like, with kcompactd, we dont need direct_compact?
That will have to be evaluated. It would be nice to not need the
compact/reclaim loop, but I'm not sure it's always possible. We could
move it to kcompactd, but it would still mean that no daemon does
exclusively just reclaim or just compaction.
In embedded world situation is really worse.
As per my experience in embedded world, just compaction does not help always in longer run.
As I know there are already some Android model in market, that already run background compaction (from user space).
But still there are sluggishness issues due to bad memory state in the long run.
It should still be better with background compaction than without it. Of
course, avoiding a permanent fragmentation completely is not possible to
guarantee as it depends on the allocation patterns.
In embedded world, the major problems are related to camera and browser use cases that requires almost order-8 allocations.
Also, for low RAM configurations (less than 512M, 256M etc.), the rate of failure of compaction is much higher than the rate of success.
I was under impression that CMA was introduced to deal with such
high-order requirements in the embedded world?
How can we guarantee that kcompactd is suitable for all situations?
We can't :) we can only hope to improve the average case. Anything that
needs high-order *guarantees* has to rely on CMA or another kind of
reservation (yeah even CMA is a pageblock reservation in some sense).
In an case, we need large amount of testing to cover all scenarios.
It should be called at the right time.
I dont have any data to present right now.
May be I will try to capture some data, and present here.
That would be nice. I'm going to collect some as well.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/