Messages in this thread | | | Subject | Re: Externalize SLIT table | From | Matthew Dobson <> | Date | Wed, 10 Nov 2004 14:09:20 -0800 |
| |
On Wed, 2004-11-10 at 10:45, Erich Focht wrote: > On Wednesday 10 November 2004 06:05, Mark Goodwin wrote: > > On a system that has nodes with multiple sockets (each supporting > > multiple cores or HT "CPUs" sharing some level of cache), when the > > scheduler needs to migrate a task it would first choose a CPU > > sharing the same cache, then a CPU on the same node, then an > > off-node CPU (i.e. falling back to node distance). > > This should be done by correctly setting up the sched domains. It's > not a question of exporting useless or redundant information to user > space. > > The need for some (any) cpu-to-cpu metrics initially brought up by > Jack seemed mainly motivated by existing user space tools for > constructing cpusets (maybe in PBS). I think it is a tolerable effort > to introduce in user space an inlined function or macro doing > something like > cpu_metric(i,j) := node_metric(cpu_node(i),cpu_node(j)) > > It keeps the kernel free of misleading information which might just > slightly make cpusets construction more comfortable. In user space you > have the full freedom to enhance your metrics when getting more > details about the next generation cpus.
Good point, Erich. I don't think there is any desperate need for CPU-to-CPU distances to be exported to userspace right now. If that is incorrect and someone really needs a particular distance metric to be exported by the kernel, we can look into that and export the required info. For now I think the Node-to-Node distance information is enough. -Matt
- 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/
| |