Re: [RFC][PATCH] cpus_allowed/launch_policy patch, 2.4.16

[Matthew Dobson]

Robert Love wrote:
> 
> On Wed, 2001-12-05 at 21:17, Matthew Dobson wrote:
> 
> > but, as soon as one of them exec()'s their no longer going to be using your
> > functions.
> 
> But cpus_allowed is inherited, so why does it matter?
You're right, cpus_allowed would inherit just fine on its own, but...

> 
> The only benefit I see to having it part of the fork operation as
> opposed to Ingo's or my own patch, is that the parent need not be given
> the same affinity.
...this is the important part.  As soon as you start a process executing 
on a particular CPU/Node (more important on a NUMA box) it begins to develop
a memory footprint.  Things start getting allocated to that CPU's or Node's
memory.  When you push the process to a different node for no good reason
(just to fork() and then come back to the original node) it is inefficient.
You are going to be causing all kinds of remote memory accesses that don't need
to happen.  As the kernel gets more NUMA-aware, this will be even more of a
discrepancy between the two methods.

> 
> And honestly I don't see that as a need.  You could always change it
> back after the exec.  If that is unacceptable (you point out the cost of
> forcing a task on and off a certain CPU), you could just have a wrapper
> you exec that changes its affinity and then it execs the children.
This seems to me to be a bit of a kludgy (although perfectly valid) way of 
doing something that could be done much more elegantly and efficiently with 
a launch_policy.  If you use the wrapper method, the task structure and 
various other internal kernel data structures could be allocated on the
incorrect node.  This data will eventually migrate to the correct place,
but why start the process out on the wrong foot, when the cost of doing
the correct allocation is so small (or nonexistent)?

Cheers!

-matt