On 10/11/2012 11:53 AM, Mel Gorman wrote:
On Thu, Oct 04, 2012 at 01:50:57AM +0200, Andrea Arcangeli wrote:
This is where the dynamically allocated task_autonuma structure is
being handled.
This is the structure holding the per-thread NUMA statistics generated
by the NUMA hinting page faults. This per-thread NUMA statistical
information is needed by sched_autonuma_balance to make optimal NUMA
balancing decisions.
It also contains the task_selected_nid which hints the stock CPU
scheduler on the best NUMA node to schedule this thread on (as decided
by sched_autonuma_balance).
The reason for keeping this outside of the task_struct besides not
using too much kernel stack, is to only allocate it on NUMA
hardware. So the non NUMA hardware only pays the memory of a pointer
in the kernel stack (which remains NULL at all times in that case).
If the kernel is compiled with CONFIG_AUTONUMA=n, not even the pointer
is allocated on the kernel stack of course.
Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx>
There is a possibility that someone will complain about the extra
kmalloc() during fork that is now necessary for the autonuma structure.
Microbenchmarks will howl but who cares -- autonuma only makes sense for
long-lived processes anyway. It may be necessary in the future to defer
this allocation until the process has consumed a few CPU seconds and
likely to hang around for a while. Overkill for now though so
That is indeed a future optimization I have suggested
in the past. Allocation of this struct could be deferred
until the first time knuma_scand unmaps pages from the
process to generate NUMA page faults.
Acked-by: Mel Gorman <mgorman@xxxxxxx>
--
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>