> I'm currently working on adding multiprocessor control interfaces
> to Linux. My current efforts can be found here:
>
> http://www.ccur.com/realtime/oss
>
> These are clean-room implementations of similar tools that have
> been available in our proprietary *nix for quite some time, and
> so the interfaces have a fair amount of mileage under their belts.
> Note that the scope is somewhat wider than just MP.
Ahh, very neat. This is a useful tool.
One idea would be to allow users to set CPUs processes _can't_ run on.
On high-end systems sometimes a CPU is affined to a particular IRQ (say,
network interface). Another situation is where you bind a RT task to a
given CPU. In these situations, you want everything else to _not_ run
on the CPUs. I.e., `run --bind=!1' (note its easy to generate the
bitmask here too, by ANDing the inverse of the given CPU against -1).
At any rate, what is needed most is to standardize on an interface for
these scheduling mechanisms. I guess its just CPU affinity we have to
go ... since not much progress was made of my (proc-based) method vs.
Ingo's (syscall-based) method, at this point either of the two being
merged would make me happy.
> These services rely upon Robert Love's CPU Affinity patch
> (version 2.4.16-1 was used for testing) which is available here:
>
> http://www.kernel.org/pub/linux/kernel/people/rml/cpu-affinity/v2.4/
I assume you have no problems with it ... I think I'd like to add the
change that the CPUs reported correspond to the physical CPU number and
not the logical value we derive. On x86 this won't make a difference,
but its a proper method I suspect.
Robert Love
-
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/