<div dir="ltr"><div>Hello,</div><div dir="ltr"><br></div><div dir="ltr">Because machine configurations may change during development, we used a microbenchmark to try to isolate the cause and reproduce the long DBus latencies reliably, and another microbenchmark to demonstrate the idea we had tried that appeared to alleviate but not completely eliminate this DBus latency problem.</div><div dir="ltr"><br></div><div>The first microbenchmark, dbus-asio-bmk (<a href="https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-tools/+/35576">https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-tools/+/35576</a>) mimics our patched psusensor: an ASIO worker that reads sensors at some fixed timer interval; the ASIO worker is also used by sdbusplus for handling DBus work. We continuously run "busctl tree" against the DBus interface created by the microbenchmark binary.</div><div><br></div><div>By importing the resultant DBus traffic dump and ASIO handler activity log onto the timeline view form dbus-vis, we can clearly see the the "sensor reading" ASIO work items block the DBus work items, which in turn causes very long DBus latencies to show up:</div><div><br></div><div><div><img src="cid:ii_kds09p6b0" alt="busctlubmk.png" width="542" height="200">Although this benchmark is run on an x86 workstation instead of the BMC due to a run-time error in its dependencies, according to the results above, we see this "thundering herd" problem appear to occur on a desktop platform as well.</div><div><br></div><div>As we modify various experimental parameters, it turns out that the more time is occupied by non-DBus ASIO work the more likely long DBus latencies are to happen, since there is a higher chance the DBus calls clash with the "fake sensor reading". Thus, we come up with an assumption that if we reduce the time spent (by the only ASIO worker) in non-DBus ASIO work, DBus latencies will be reduced.</div><div><br></div><div>Based on this assumption, we attempted a few methods to reduce the time it takes psusensor to read the sensors. The second benchmark (<a href="https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-tools/+/35387">https://gerrit.openbmc-project.xyz/c/openbmc/openbmc-tools/+/35387</a>) explains the methods we had experimented with. It turns out we were able to reduce sensor reading time as well as the chance of long DBus method calls happening, but the inconsistent DBus call times do not completely go away. This is probably due to psusensors being much more complex than the two benchmarks with much other work contending for the ASIO worker's time.</div><div><br></div><div>So to summarize the point of this reply is to say:</div><div>1) We had attempted the ASIO handler dump as suggested and a method for analyzing DBus+ASIO performance has been embodied in dbus-vis.</div><div>2) We are interested to know if someone else is looking at similar problems.</div><div>3) We will examine GetManagedObjects again when we get a chance.</div><div><br></div><div>Thanks,</div><div>Sui</div></div></div>