On 07/24/2015 04:22 PM, Rik van Riel wrote:
On 07/02/2015 04:46 AM, Vlastimil Babka wrote:
This RFC series is another evolution of the attempt to deal with THP
allocations latencies. Please see the motivation in the previous version [1]
The main difference here is that I've bitten the bullet and implemented
per-node kcompactd kthreads - see Patch 1 for the details of why and how.
Trying to fit everything into khugepaged was getting too clumsy, and kcompactd
could have more benefits, see e.g. the ideas here [2]. Not everything is
implemented yet, though, I would welcome some feedback first.
This leads to a few questions, one of which has an obvious answer.
1) Why should this functionality not be folded into kswapd?
(because kswapd can get stuck on IO for long periods of time)
Hm, my main concern was somewhat opposite - kswapd primarily serves to
avoid direct reclaim (also for) order-0 allocations, so we don't want to
make it busy compacting for high-order allocations and then fail to
reclaim quickly enough.
Also the waking up of kswapd for all the distinct tasks would become
more complex.
Also does kswapd really get stuck on IO? Doesn't it just issue writeback
and go on? Again it would be the opposite concern, as sync compaction
may have to wait for writeback before migrating a page and blocking
kswapd on that wouldn't be nice.
2) Given that kswapd can get stuck on IO for long periods of
time, are there other tasks we may want to break out of
kswapd, in order to reduce page reclaim latencies for things
like network allocations?
(freeing clean inactive pages?)
--
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>