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 <[email protected]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
