Bug 1294658

Summary: [RFE] Add lstopo text output to sosreport
Product: Red Hat Enterprise Linux 7 Reporter: Herton R. Krzesinski <hkrzesin>
Component: sosAssignee: Pavel Moravec <pmoravec>
Status: CLOSED DUPLICATE QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: agk, bmr, dkutalek, gavin, hkrzesin, plambri, sbradley
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-17 12:46:01 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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 6 Bryn M. Reeves 2016-01-11 09:40:32 EST
https://github.com/sosreport/sos/issues/
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 ***