Bug 1294658

lstopo is a nice toy to show the topology of the system. But..

- package hwloc-gui that contains it is not present in most of RHEL deployments. Since it requires a X11 library. So the command wont be installed / wont provide any data for most RHEL machines.

- what additional value/information the tool provides, that is not collected by current sosreport?

- when such information can be valuable in investigation of a problem?

(basically: please provide classic RFE template / answers from it)

(In reply to Pavel Moravec from comment #2)
> lstopo is a nice toy to show the topology of the system. But..
> 
> - package hwloc-gui that contains it is not present in most of RHEL
> deployments. Since it requires a X11 library. So the command wont be
> installed / wont provide any data for most RHEL machines.

If sos uses /usr/bin/lstopo-no-graphics from hwloc package there is no X11 dependency which I can see:

# rpm -qf /usr/bin/lstopo-no-graphics
hwloc-1.7-5.el7.x86_64
# rpm -q --requires hwloc
/bin/sh
hwloc-libs = 1.7-5.el7
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libdl.so.2()(64bit)
libhwloc.so.5()(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libnuma.so.1()(64bit)
libpciaccess.so.0()(64bit)
libtinfo.so.5()(64bit)
libxml2.so.2()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1
# rpm -q --requires hwloc-libs
/sbin/ldconfig
/sbin/ldconfig
libc.so.6()(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libdl.so.2()(64bit)
libm.so.6()(64bit)
libnuma.so.1()(64bit)
libnuma.so.1(libnuma_1.1)(64bit)
libnuma.so.1(libnuma_1.2)(64bit)
libpciaccess.so.0()(64bit)
libxml2.so.2()(64bit)
libxml2.so.2(LIBXML2_2.4.30)(64bit)
libxml2.so.2(LIBXML2_2.6.0)(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rtld(GNU_HASH)
rpmlib(PayloadIsXz) <= 5.2-1

> 
> - what additional value/information the tool provides, that is not collected
> by current sosreport?

It provides for example which pci bus/devices are bound to some specific NUMA node. I don't see sosreport at least in RHEL 7 include numa_node files from /sys (/sys/devices/pci*/*/numa_node). Anyway, the whole point of the utility is to present all the information in a concise and readable way, instead of you having to dig through all /sys files etc.

There are some good examples on this page of lstopo output: https://www.open-mpi.org/projects/hwloc/lstopo/

> 
> - when such information can be valuable in investigation of a problem?

Checking device numa node info and using that for IRQ affinity/numa task affinity policy (tuning) is one use case I see it may be useful.

Another example, even though this isn't the main purpose of lstopo, I also like the fact that you can quickly see for example which block devices are assigned for which pci device, while in the current sosreport you have to dig in lsblk then look at dmesg and that takes more time.

> 
> (basically: please provide classic RFE template / answers from it)

"It would be nice" is not justification to add something to RHEL; as Pavel asked, please fill out the bugzilla template sections when filing RHEL bugs (or provide equivalent explanation in another format).

I wouldn't have a strong objection to adding this upstream but it does requires some justification since it is collecting information that is already present (albeit in different forms).

The preference for sos upstream is to collect data once in a canonical format (/sys captures for e.g.) and to allow presentation and transformation to take place on the analysis host. This isn't always possible with current tooling and that is why requests like this need to explain why their usefulness outweighs the cost of carrying more redundant collection.

We all know what the tool can output - it's why that is particularly valuable and the problems it solves that matter when considering inclusion in RHEL.

Ok, perhaps I should have opened this bug for upstream sos instead of RHEL directly (open against Fedora sos?). I justified the reasons I see for lstopo on comment #3. Anyway, I just wanted to raise quickly an issue against sos suggesting that lstopo output is useful. If you decide it's not or the reasons are not worth for inclusion, feel free to close this, or repurpose this bug to include the files with numa node information at /sys with sosreports.

https://github.com/sosreport/sos/issues/

I created a new "issue" here: https://github.com/sosreport/sos/issues/719

See my suggestion about hwloc-gather-topology: if sosreport includes same /proc* /sys* which hwloc-gather-topology includes in the tarball it creates, then you would need only that and could run then lstopo -i against a extracted sosreport. sos would need to include only missing files not yet included. I think this addresses concerns here about collecting duplicate information.

I would like to get this into 7.3, either included in errata directly, or indirectly due to https://bugzilla.redhat.com/show_bug.cgi?id=1293044 .

There is duplicate bz1308998 . Despite usually I would close that one as DUP, I will close this one due to flags and dependency BZ in these two BZs.

*** This bug has been marked as a duplicate of bug 1308998 ***