On 10/28/2014 08:58 AM, Rik van Riel wrote:
On 10/28/2014 08:12 AM, Andi Kleen wrote:
Alex Thorlton <athorlton@xxxxxxx> writes:
Last week, while discussing possible fixes for some unexpected/unwanted behavior
from khugepaged (see: https://lkml.org/lkml/2014/10/8/515) several people
mentioned possibly changing changing khugepaged to work as a task_work function
instead of a kernel thread. This will give us finer grained control over the
page collapse scans, eliminate some unnecessary scans since tasks that are
relatively inactive will not be scanned often, and eliminate the unwanted
behavior described in the email thread I mentioned.
With your change, what would happen in a single threaded case?
Previously one core would scan and another would run the workload.
With your change both scanning and running would be on the same
core.
Would seem like a step backwards to me.
It's not just scanning, either.
Memory compaction can spend a lot of time waiting on
locks. Not consuming CPU or anything, but just waiting.
I am not convinced that moving all that waiting to task
context is a good idea.
It may be worth investigating how the hugepage code calls
the memory allocation & compaction code.
Doing only async compaction from task_work context should
probably be ok.
--
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>