On 10/11/2012 01:59 PM, Andrea Arcangeli wrote:
On Thu, Oct 11, 2012 at 01:34:12PM -0400, Rik van Riel wrote:
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.
I already tried this, and quickly noticed that for mm_autonuma we
can't, or we wouldn't have memory to queue the "mm" into knuma_scand
in the first place.
For task_autonuma we could, but then we wouldn't be able to inherit
the task_autonuma->task_autonuma_nid across clone/fork which kind of
makes sense to me (and it's done by default without knob at the
moment). It's actually more important for clone than for fork but it
might be good for fork too if it doesn't exec immediately.
Another option is to move task_autonuma_nid in the task_structure
(it's in the stack so it won't cost RAM). Then I probably can defer
the task_autonuma if I remove the child_inheritance knob.
In knuma_scand we don't have the task pointer, so task_autonuma would
need to be allocated in the NUMA page faults, the first time it fires.
One thing that could be done is have the (few) mm and
task specific bits directly in the mm and task structs,
and have the sized-by-number-of-nodes statistics in
a separate numa_stats struct.
At that point, the numa_stats struct could be lazily
allocated, reducing the memory allocations at fork
time by 2 (and the frees at exit time, for short lived
processes).
--
All rights reversed
--
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>