Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[RFE] Add lstopo text output to sosreport|
|Product:||Red Hat Enterprise Linux 7||Reporter:||Herton R. Krzesinski <hkrzesin>|
|Component:||sos||Assignee:||Pavel Moravec <pmoravec>|
|Status:||CLOSED DUPLICATE||QA Contact:||BaseOS QE - Apps <qe-baseos-apps>|
|Version:||7.3||CC:||agk, bmr, dkutalek, gavin, hkrzesin, plambri, sbradley|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2016-02-17 12:46:01 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Herton R. Krzesinski 2015-12-29 08:47:49 EST
Description of problem: It would be nice if sosreports included text output from lstopo. Eg. from my laptop here: # lstopo --output-format console --taskset --whole-io Machine (7685MB) cpuset=0xf Package L#0 cpuset=0xf L3 L#0 (4096KB) cpuset=0xf L2 L#0 (256KB) cpuset=0x3 L1d L#0 (32KB) cpuset=0x3 L1i L#0 (32KB) cpuset=0x3 Core L#0 cpuset=0x3 PU L#0 (P#0) cpuset=0x1 PU L#1 (P#1) cpuset=0x2 L2 L#1 (256KB) cpuset=0xc L1d L#1 (32KB) cpuset=0xc L1i L#1 (32KB) cpuset=0xc Core L#1 cpuset=0xc PU L#2 (P#2) cpuset=0x4 PU L#3 (P#3) cpuset=0x8 Misc(MemoryModule) Misc(MemoryModule) HostBridge L#0 PCI 8086:0154 PCI 8086:0166 GPU L#0 "card0" GPU L#1 "renderD128" GPU L#2 "controlD64" PCI 8086:1e31 PCI 8086:1e3a PCI 8086:1e3d PCI 8086:1502 Net L#3 "enp0s25" PCI 8086:1e2d PCI 8086:1e20 PCIBridge PCIBridge PCI 8086:4238 Net L#4 "wlp3s0" PCIBridge PCI 1180:e823 PCIBridge PCI 8086:1e26 PCI 8086:1e55 PCI 8086:1e03 Block(Disk) L#5 "sda" Block(Removable Media Device) L#6 "sr0" PCI 8086:1e22 Version-Release number of selected component (if applicable): sos
Comment 2 Pavel Moravec 2015-12-30 02:53:16 EST
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)
Comment 3 Herton R. Krzesinski 2015-12-30 08:41:30 EST
(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)
Comment 4 Bryn M. Reeves 2016-01-11 08:19:30 EST
"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.
Comment 5 Herton R. Krzesinski 2016-01-11 09:19:37 EST
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.
Comment 7 Herton R. Krzesinski 2016-01-11 20:44:42 EST
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.
Comment 8 Pavel Moravec 2016-02-17 12:46:01 EST
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 ***