Peter wrote:
Of course, this [kernel compile option] makes gradual movement
from one model to the other difficult to say the least.
To say the least.
It might be possible to continue to support current affinity calls
(setaffinity/mbind/mempolicy) even while removing the duplication of
affinity masks between tasks and cpusets.
If each call to set a tasks affinity resulted in moving that task into
its very own cpuset (unless it was already the only user of its cpuset),
and if the calls to load and store task->{cpus,mems}_allowed in the
implementation of these affinity sys calls were changed to load and
store those affinity masks in the tasks cpuset instead.
I'm just brainstorming here ... this scheme could easily have some
fatal flaw that I'm missing at the moment.