Messages in this thread | | | Subject | Re: [RFC] Multiprocessor Control Interfaces | From | Robert Love <> | Date | 11 Dec 2001 01:29:07 -0500 |
| |
On Mon, 2001-12-10 at 15:14, Jason Baietto wrote:
> 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/
| |