Re: [PATCH v2 0/5] introduce kcompactd and stop compacting in kswapd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/09/2016 04:52 PM, Michal Hocko wrote:
On Mon 08-02-16 14:38:06, Vlastimil Babka wrote:
The previous RFC is here [1]. It didn't have a cover letter, so the description
and results are in the individual patches.

FWIW I think this is a step in the right direction. I would give my

Thanks!

Acked-by to all patches but I wasn't able to find time for a deep review
and my lack of knowledge of compaction details doesn't help much. I do
agree that conflating kswapd with compaction didn't really work out well
and fixing this would just make the code more complex and would more
prone to new bugs.

Yeah, it seems that direct reclaim/compaction is complex enough already...

In future we might want to invent something similar
to watermarks and set an expected level of high order pages prepared for
the allocation (e.g. have at least XMB of memory in order-9+). kcompact
then could try as hard as possible to provide them. Does that sound at
least doable?

Sure, that was/is part of the plan. But I was trimming the series for initial merge over the past year to arrive at a starting point where reaching consensus is easier.

Thanks!


--
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>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]