Messages in this thread | | | Date | Wed, 5 Dec 2001 18:08:33 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [RFC][PATCH] cpus_allowed/launch_policy patch, 2.4.16 |
| |
On Wed, 5 Dec 2001, Matthew Dobson wrote:
> In response (albeit a week plus late) to the recent hubbub about the cpu > affinity patches, > I'd like to throw a third contender in the ring. > > Attatched is a patch (against 2.4.16) which implements a /proc and a prctl() > interface to > the cpus_allowed flag. The truly exciting (at least for me) part of this patch > is the > launch_policy flag that it also introduces. The launch_policy flag is used > similarly to > the cpus_allowed flag, but it controls the cpus_allowed flags of any subsequent > children > of the process, instead of the cpus_allowed of the process itself. Via this > flag, there > are no worries about processes being able to fork children before a 'chaff' or > 'echo' or > anything else for that matter can be executed. The child process is assigned > the desired > cpus_allowed at fork/exec time. All this without having to bounce the current > process to > different cpus to (hopefully) acheive the same results. > > The launch_policy flag can acually be quite powerful. It allows for children > to be > instantiated on the correct cpu/node with a minimum of memory footprint on the > wrong > cpu/node. This can be taken advantage of via the /proc interface (for smp/numa > unaware > programs) or through prctl() for more clueful programs.
What you probably want to do in real life is to move a process to a cpu and have all its child spawned on that cpu, that is the actual behavior. Can't You achieve the same by coding a :
pid_t affine_fork(int cpumask) { pid_t pp = fork(); if (pp == 0) { set_affinity(getpid(), cpumask); ... } return pp; }
in your application and having the default bahavior to propagate it to the following fork()s.
> +int proc_pid_cpus_allowed_read(struct task_struct *task, char * buffer) ^^^^^^^^^^^^^^^^^^^^^^^^^^ You want Al Viro screaming, don't You ? :)
- Davide
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |