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.

You must have CAP_SYS_NICE or be the owner of the process to change *either*
cpus_allowed or launch_policy.

I will momentarily be posting this patch in its own thread for greater
exposure.

Feedback of any kind will be greatly appreciated!

Enjoy!

-matt

Linux maillist account wrote:
> 
> At 11:49 PM 11/26/01 -0500, Robert Love wrote:
> >I can see the use for this, but you can also just do `echo whatever >
> >/proc/123/affinity' once it is running ... not a big deal.
> 
> It's isn't quite the same..the biggest difference is races.  The cpuselect(1)
> tool would change the affinity mask before the fork & exec of the first
> child.  To
> do this by hand via an `echo whatever >/proc/123/affinity' would miss all the
> children spun off by 123 before the echo could be executed.  One could write
> cpuselect as a shell script I suppose, using within it an echo on
> /proc/self/affinity,
> though even as a shell script it would be better to have this tool be part
> of the standard
> Linux repetoire that everyone could depend upon as being there in all Linux
> distributions
> and having a well known and unchanging syntax and semantics,  rather than
> have it
> remain something that each user creates ad-hoc as the need for the tool arises.
> 
> Joe
> 
> -
> 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/