Messages in this thread | | | Date | Mon, 6 Feb 2006 00:35:57 -0800 | From | Paul Jackson <> | Subject | Re: [PATCH 1/5] cpuset memory spread basic implementation |
| |
Ingo wrote: > if we want to reduce complexity, i'd suggest to consolidate the MPOL_* > mechanism into cpusets, and phase out the mempolicy syscalls. (The sysfs > interface to cpusets is much cleaner anyway.)
I think that there is an essential place for both interfaces.
Individual tasks need to be able to micromanage their memory placement and (with sched_setaffinity) cpu scheduling. For instance, the cpuset interface would be ill equipped to express the virtual address-range placement that the mbind(2) system call can express.
Also the cpuset interface affects all tasks equally that are in that cpuset, which is simply not enough. Individual threads have their own special needs, which they are prepared to express in code.
We might have details of the mempolicy system calls that we don't like; I've complained about such myself in times long past. But it is quite servicable, and the API details are probably better left as they are. Incompatible changes would cause more problems than we fixed.
The two separate interfaces really do fit the end-usage pattern rather well. We have cpusets for the sysadmins and batch schedulers, and we have the schedaffinity and mempolicy system calls for the applications.
I will grant that it's a pleasure, after all these years, to be arguing that "we need mempolicy too", rather than arguing "we need cpusets in addition."
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 - 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/
| |