Messages in this thread | | | Date | Wed, 19 Jun 2002 01:57:48 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: latest linus-2.5 BK broken |
| |
On 18 Jun 2002, Michael Hohnbaum wrote:
> A bit mask is a very good choice for the sched_setaffinity() > interface. [...]
thanks :)
> [...] I would suggest an additional argument be added > which would indicate the resource that the process is to be > affined to. That way this interface could be used for binding > processes to cpus, memory nodes, perhaps NUMA nodes, and, > as discussed recently in another thread, other processes. > Personally, I see NUMA nodes as an overkill, if a process > can be bound to cpus and memory nodes.
are you sure we want one generic, process-based affinity interface?
i think the affinity to certain memory regions might need to be more finegrained than this. Eg. it could be useful to define a per-file (per-inode) 'backing store memory node' that the file is affine to. This will eg. cause the pagecache to be allocated in the memory node. Process-based affinity does not describe this in a natural way. Another example, memory maps: we might want to have a certain memory map (vma) allocated in a given memory node, independently of where the process that is faulting a given pages resides.
and it might certainly make sense to have some sort of 'default memory affinity' for a process as well, but this should be a different syscall - it really does a much different thing than CPU affinity. The CPU resource is 'used' only temporarily with little footprint, while memory usage is often for a very long timespan, and the affinity strategies differ greatly. Also, memory as a resource is much more complex than CPU, eg. it must handle things like over-allocation, fallback to 'nearby' nodes if a node is full, etc.
so i'd suggest to actually create a good memory-affinity syscall interface instead of trying to generalize it into the simple, robust, finite CPU-affinity syscalls.
Ingo
- 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/
| |