Brice Goglin, le Mon 03 Nov 2014 11:49:02 +0100, a écrit : > * kerrighed support (single-system image): planned for removal since > 2012, see https://github.com/open-mpi/hwloc/issues/73
Right, Kerrighed is mostly discontinued. > I am also considering this change that shouldn't break existing programs: > * always create a NUMA node even if the machine isn't NUMA That makes sense to me, yes. > If we're going to break the ABI anyway (removing custom will break the > ABI), we could break it even more. Yes, sure, a 2.0 is the opportunity to break the ABI/API a bit. > * don't put I/O objects in "normal" children since it confuses programs > consulting the children list. rather place them under a dedicated child > pointer special objects such as Misc may go there as well. Indeed. > * replace hwloc_topology_ignore_type_keep_structure() with a flavor that > does not create asymmetric topologies. only remove entire levels that > don't add any hierarchy. don't remove single objects within levels in > case of asymmetric topologies (restricted by cgroup etc). Agreed. > * remove obj->os_level: pretty much unused and undocumented, can go in a > string attribute if really useful Indeed. This was introduced for AIX, and later re-used by x86, but applications most probably won't really make use of it. I don't think it's even useful to put it in an attribute. > Changes requested by some users but that I am not sure what to do yet: > * stop having 4 cpusets and 3 nodesets per object and just have 1 cpuset > and 1 nodeset depending on topology flags (only allowed, or only online, > etc). possibly with ways to switch between modes at runtime Right, I can understand it scares users to get all this information . Having to choose at runtime however poses the problem of applications which would want the various information, to deal with both online and allowed, lstopo is such an example, because they wouldn't like to have to build the topology several times to get the various information. What I guess would work fine is to have only the cpuset and nodeset fields, have a flag to decide between cpuset/nodeset being the complete sets or just what is covered by PU object (the latter being the default, probably), and provide the allowed and online cpuset/nodesets another way: we don't need it in all objects anyway, since one can always perform an AND of allowed or online with the object cpuset to get what one wants. Considering the netloc support, I guess the information should be contained in the machine object. > * stop having a CACHE type + data/instruction/unified + depth, and just > have one type for each of them, such as HWLOC_OBJ_CACHE_L1d. the > advantage is that you can switch (type) without special-casing the CACHE > subtypes. One drawback is that there are many subtypes in existing > machines (at least L1[id], L2[idu], L3[idu], L4u). Yes, and we don't know when it will end. We had only L1 in the past, then L1-L2, then L1-L3, then L1-L4, ... :) It would be a pity to abandon providing applications with a level-agnostic way to deal with caches. Separating instruction cache from data caches seems reasonable to me, however. > Also the "Group" type still needs special-casing because of multiple > nested groups in large NUMA machines. Which kind of special-casing do we see in the wild? I would usually consider groups as something applications can't really take into account more precisely than the mere topology division. Samuel
