Messages in this thread |  | | Date | Tue, 28 Oct 2014 11:39:20 -0400 | From | Rik van Riel <> | Subject | Re: [PATCH 0/4] Convert khugepaged to a task_work function |
| |
On 10/28/2014 08:58 AM, Rik van Riel wrote: > On 10/28/2014 08:12 AM, Andi Kleen wrote: >> Alex Thorlton <athorlton@sgi.com> 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.
|  |