Paul Jackson wrote:
Peter writes:

The way I see it you just replace the task's affinity mask with a pointer to its "CPU set" which contains the affinity mask shared by tasks belonging to that set ...


I too like this suggestion.  The current duplication of cpus_allowed and
mems_allowed between task and cpuset is a fragile design, forced on us
by incremental feature addition and the need to maintain backwards
compatibility.

OK.


A possible problem is that there may be users whose use of the current affinity mechanism would be broken by such a change. A compile time choice between the current mechanism and a set based mechanism would be a possible solution.


Do you mean kernel or application compile time?

Kernel compile time.

 The current affinity
mechanisms have enough field penetration that the kernel will have to
support or emulate these calls for a long period of deprecation at best.

That's unfortunate. Are the (higher level) ways in which they're used incompatible with CPU sets or would CPU sets be seen as being a better (easier) way of doing the job?


If the choice is at kernel compile time then those users of the current mechanism can choose it and new users can choose CPU sets. Of course, this makes gradual movement from one model to the other difficult to say the least.


So I guess you mean application compile time. However, the current user level support, in glibc and other libraries, for these calls is sufficiently confused, at least in my view, that rather than have that same API mean two things, depending on a compile time switch, I'd rather explore (1) emulating the existing calls, just as they are, (2) adding new calls that are try these API's again, in line with our kernel changes, and (3) eventually deprecate and remove the old calls, over a multi-year period.

I would agree with that. I guess that emulation would not be possible on top of my suggestion hence the requirement for the "fragile design" etc.


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

Reply via email to