At boot the system creates a PSet with ALL processors, and one set for each
single CPU. Root can define extra sets with specified CPUs, too.
Processes can then run (commandline tool = 'runon') on a specific Pset.
runon 3 yes # runs on PSET #3
This is ok, but it has several drawbacks:
* user can not run on an arbitrary set of procs
* defining a set for every combination of procs is ludicrous
However, it has several upsides
* disabling a CPU is as simple as removing it from a pset struct, not
iterating over all tasks
* conceptually hides the 'bitmask of CPUs'
> It duplicates some stuff set elsewhere, and seems more than a bit like
> ioctl(2) by another name, but doesn't seem too bad. Note we should be
> careful not to overengineer the interface, either...
At some point Ralf Baechle asked me to extend it more for IRIX
compatibility. We may want to just drop that altogether. Several of the
sysmp() interfaces can be handled at the library layer and re-routed to
their existing interfaces.
> Just setting a bitmask does seem a bit limiting when thinking about the
> future, agreed.
What is the future of the existing CPUs bitmask? Is it becoming something
else?
Perhaps we want to keep sysmp() in name and form, perhaps just in name,
perhaps not at all. This is an area in which I have (had, but could get
again) a lot of interest, but before I waste any more time on it, I'd like
to actually co-design a feature set.
What do we want:
* unpriviliged ability to change current->pset?
- any user can call sysmp(MP_RUNON) anytime
* privileged ability only (runon becomes suid)
- can "trap" processes to a CPU - it has been requested a lot
* processor sets or just bitmasks/lists?
- someone was working on memory sets, similarly to psets
If we really want this, I definately want to help. :)
Tim
-
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/