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.
Provided overlapping sets are allowed it should be feasible. However, I'm not a big fan of overlapping sets as it would make using different CPU scheduling configurations in each set more difficult (maybe even inadvisable) but that's a different issue.
Peter -- Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
