openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Geissler <geissonator@gmail.com>
To: Pasha Ghabussi <pashag@google.com>
Cc: openbmc@lists.ozlabs.org
Subject: Re: BMC Performance Profiler
Date: Fri, 9 Oct 2020 09:37:21 -0500	[thread overview]
Message-ID: <50E8C07A-985E-4645-91BF-5ADF7D1D40B4@gmail.com> (raw)
In-Reply-To: <CA+-TXo-4MCkDwKG2087pgZsqgezfxda6LUWOv5GCtLK5k=cjUQ@mail.gmail.com>



> On Oct 8, 2020, at 4:44 PM, Pasha Ghabussi <pashag@google.com> wrote:
> 
> Hello all,
> 
> We would really appreciate it if you can take a few minutes to read the proposal sent earlier and let us know your thoughts and suggestions.
> 
> Thank you
> 
> On Mon, Oct 5, 2020 at 1:57 PM Pasha Ghabussi <pashag@google.com> wrote:
> Hello all,
> We would really appreciate it if you can take a few minutes to read the following proposal and let us know your thoughts and suggestions.
> We are developing a tool to investigate performance problems by looking at DBus traffic dumps.

I definitely think this could be a very useful tool. Performance issues have hindered us from day 1 with OpenBMC and countless hours have gone into trying to identify the different issues. One area we’ve seen a lot of issues with is on BMC startup, especially after a firmware update. If you could provide a way to enable the needed profiling debug, and then reboot the BMC and capture the data for analysis, it would be appreciated.

> Current DBus inspection and visualization tools do not represent the DBus events similar to a typical performance profiler. Additionally, these tools do not address typical BMC workloads such as IPMI and ASIO. Hence, identifying potential performance problems requires inspecting the raw BMC DBus traffic, which can become a long and complex process. We want to add a graphical interface to webui-vue to visualize the DBus traffic to address the abovementioned problem.

Will you be using something like "busctl capture” to capture the data? I hope you don’t have to write a new tool to get the data? 


> 
> There have been DBus and IPMI performance-related discussions in the OpenBMC community, both of which can be helped by this work: IPMI-related issues started to appear as early as in 2017. One issue (#2630) describes a problem related to large numbers of sensors. Its follow-up (#3098) mentions “hostboot crashes due to poor IPMI performance”. Another issue (#2519) describes a commonly-seen problem of IPMI taking very long to respond (> 5s).
> There are also discussions on RedFish performance on the mailing list; A patch optimized DBus performance by introducing a cache for name translation.
> All the performance investigations listed above involve DBus and may be helped by this work.

Agreed

> 
> We are planning to use the BMCweb file hosting functionality to access the DBus event dumps and visualize the events in the web UI. The available profiling tools such as dbus-pcap, Wireshark, Bustle, Snyh, or DFeet do not provide the exact functionality we are looking for. Our goal is to develop functionalities similar to other widely used profilers such as GPUView or VTune Profiler.
> 

For the analysis and visualization side, I’m never a big fan of writing something from scratch. Have you looked into enhancing some of the existing tools out there vs. writing your own?

Although having in the web UI could be useful, I don’t really see it as a requirement. Could your tool be simpler to write or be made more generic for others to use if it was not tied to the web UI?

> One alternative solution considered was to stream DBus requests over websocket, but the existing websocket endpoints available on BMC webserver do not provide the exact information we need.
> 
> Requirements and Scalability:
> 	• Should provide the adequate functionalities to filter, visualize the events timeline, and group the DBus traffic based on multiple criteria such as type, source, destination, path, interface, demon signatures, and more.
> 	• Should support capture of DBus messages using as little resources as possible.
> 	• Should be able to show many (~thousands of) entries on screen simultaneously
> 	• Integration with webui-vue
> 
> Thank you


  reply	other threads:[~2020-10-09 14:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05 17:57 BMC Performance Profiler Pasha Ghabussi
2020-10-08 21:44 ` Pasha Ghabussi
2020-10-09 14:37   ` Andrew Geissler [this message]
2020-10-09 15:45     ` Pasha Ghabussi
2020-10-09 18:53     ` Sui Chen
2020-10-26  2:02 ` Andrew Jeffery

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50E8C07A-985E-4645-91BF-5ADF7D1D40B4@gmail.com \
    --to=geissonator@gmail.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=pashag@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).