From: Paul M. <Pau...@us...> - 2001-07-08 18:04:28
|
Hello, Sam! > I am curently working on making the kernel aware of the distances that > exist, in NUMA architectures, between cpus and memories. I would like to > build a matrix of distances between each cpus and memory chunk, but I have > some hesitations here. > I would also like these distances to be readable from the /proc > filesystem. > Since I'm assuming that may be some of you are interested or even working > on the same problem, and that it would be much better to agree on some > points before going further, I need your advices, ideas, or feedback. > > I have basically three questions about it: > > 1) The term distance, in my opinion, refers to hops distances, but I > would like to know if everybody agrees on that, or if someone out there > thinks that another unit (miliseconds, Mo/s, or anything else) would be > better and more useful. We discussed this at length during the March 26 meeting in Chicago. We looked at a number of possible metrics, including latency, bandwidth, hops, etc. The problem was that all of these were quite architecture specific. We settled on an abstract notion of distance. Now, a given implementation could choose to make the distances be hops, and this might well make sense for that implementation. However, I agree with Paul Jackson when he cautions against making this a hard-and-fast rule. On many architectures, all hops are most definitely -not- created equal! > 2) I'm not sure at all wether building a generic cpu<->memory distance > matrix, or a more architecture dependent matrix, which for the SGI case > would be a node<->node distance matrix. I think a node<->node matrix would > make more sense, since this is not that architecture dependent: > node<->node for SGI, quad<->quad for some others, but basically the > same concept. The more architecture dependent it is, the less it will be used. The combination of CPU-CPU and CPU-memory distances covers a lot of ground, and is quite implementation independent (though some would argue that something is required for I/O). > 3) Concerning the /proc filesystem, I think it would be nice to agree on a > "standard" directory structure and information displaying. Something like > a /proc/numa/<arch>/<node_or_quad_or_anything_similar>n file per each > node/quad/anything similar , containing the distances between these node > and the other, may be fine. I'm not sure at all neither though... > > I would really appreciate your help/feedback on that points, and on > anything related to this distances matrix. As Kanoj noted, there is already a patch with a corresponding /proc layout. Thanx, Paul > Thanks. > > Samuel Ortiz > SGI, Intern. > Ecole des Mines de Paris, FRANCE > > > > _______________________________________________ > Lse-tech mailing list > Lse...@li... > http://lists.sourceforge.net/lists/listinfo/lse-tech |