<div dir="ltr">Hi Lei:<div>    I encounter a SEL catch sync issue. If a SEL generated while ipmd collecting all log enttry from file in SEL cache initialized progress then the SEL wouldn't be exist in SEL cache. Do you ever encounter this issue?</div><div><br></div><div>Tyler</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Lei Yu <<a href="mailto:yulei.sh@bytedance.com">yulei.sh@bytedance.com</a>> 於 2022年10月20日 週四 晚上9:26寫道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Oct 20, 2022 at 2:05 AM Bills, Jason M<br>
<<a href="mailto:jason.m.bills@linux.intel.com" target="_blank">jason.m.bills@linux.intel.com</a>> wrote:<br>
><br>
><br>
><br>
> On 10/19/2022 11:10 AM, Brad Bishop wrote:<br>
> > Thanks Jason<br>
> ><br>
> > On Wed, Oct 19, 2022 at 09:50:47AM -0600, Bills, Jason M wrote:<br>
> ><br>
> >> Intel had a requirement to support storing at least 4000 log entries.<br>
> ><br>
<br>
Bytedance has a requirement of 1000 log entries.<br>
<br>
> > Ok.  So is it fair to assume anyone using the DBus backend does not have<br>
> > this requirement?<br>
><br>
> That is my assumption, yes.<br>
> ><br>
> >> At the time, we were able to get about 400 entries on D-Bus before<br>
> >> D-Bus performance became unusable.<br>
> ><br>
> > To anyone using the DBus backend - have you observed similar performance<br>
> > issues?<br>
> ><br>
<br>
We did hit the performance issue, specifically, it is extremely slow<br>
during BMC boot, when log-manager restore the log entries and put them<br>
on DBus.<br>
That's when I start the discussion about<br>
<a href="https://gerrit.openbmc.org/c/openbmc/phosphor-logging/+/52445" rel="noreferrer" target="_blank">https://gerrit.openbmc.org/c/openbmc/phosphor-logging/+/52445</a> and<br>
<a href="https://lore.kernel.org/openbmc/CAGm54UHU9s0bTq-AR9tJunoX2Wa9tQ0PH_zWJ2QrYdR3SRqcvg@mail.gmail.com/" rel="noreferrer" target="_blank">https://lore.kernel.org/openbmc/CAGm54UHU9s0bTq-AR9tJunoX2Wa9tQ0PH_zWJ2QrYdR3SRqcvg@mail.gmail.com/</a><br>
<br>
Later we resolved the issue by:<br>
* Applying the patch<br>
<a href="https://gerrit.openbmc.org/c/openbmc/phosphor-objmgr/+/53904" rel="noreferrer" target="_blank">https://gerrit.openbmc.org/c/openbmc/phosphor-objmgr/+/53904</a><br>
* Implement the SEL cache in ipmid that is already upstreamed<br>
* Improve the SEL cache by serialization (not upstreamed)<br>
<br>
Eventually we get fair performance on SEL handling (with 1000<br>
entries), it should handle 4000 as well.<br>
<br>
> > Jason is there a testcase or scenario I can execute to highlighht the<br>
> > issues you refer to concretely?  Maybe something like "create 4000 sels,<br>
> > run ipmitool and see how long it takes?"<br>
><br>
> To clarify, my understanding is the D-Bus performance issues were not<br>
> isolated to just IPMI.  All of D-Bus for every BMC service was impacted.<br>
><br>
> If I remember correctly, Ed Tanous is who did the initial evaluation, so<br>
> he may have more detail.  But I think it was similar to what you<br>
> suggest: Create 4000 logs on D-Bus and check the performance.  This<br>
> could be done with ipmitool.<br>
> ><br>
> >> I'd also be curious about the reverse question.  Is there any benefit<br>
> >> to storing logs on D-Bus that makes it a better solution?<br>
> ><br>
> > Yes, this is exactly the question I've been trying to ask.  The answer<br>
> > seems only to be that the code is in meta-intel/intel-ipmi-oem - but<br>
> > that is easily fixed by moving the code to<br>
> > meta-phosphor/phosphor-host-ipmid.<br>
> ><br>
> >> At the risk of complicating things more (<a href="https://xkcd.com/927/" rel="noreferrer" target="_blank">https://xkcd.com/927/</a>), D-Bus<br>
> >> was the primary solution when Intel joined.  We created the rsyslog<br>
> >> approach because of the limitation imposed by D-Bus.  But I know there<br>
> >> are still those who don't like the rsyslog approach.  Is there a way<br>
> >> we can now get together and define a new logging solution that is<br>
> >> fully upstream and avoids the drawbacks of both existing solutions?<br>
> ><br>
> > I hope so, because doing that would make things a lot easier for our<br>
> > users adopting OpenBMC.<br>
><br>
> My main requirements are to store many logs (at least 4000 was the<br>
> original number, but I can try to get an updated number if needed) and<br>
> have them persist across BMC reboots.<br>
><br>
> We currently accomplish this using rsyslog to extract logs from the<br>
> journal and store them in a persistent text file.<br>
><br>
> How is best to approach starting a new design discussion?  Should we<br>
> continue discussing in this thread?  Start a design doc review?<br>
> Something else?<br>
> ><br>
> > Thanks,<br>
> > brad<br>
<br>
I would like to add several notes (possibly limitations) about<br>
rsyslog's SEL in intel-ipmi-oem, please correct if I was wrong.<br>
* It handles the SELs from phosphor-sel-logger, mostly it only<br>
contains the threshold events.<br>
* It iterates the sel files, and convert the file content into SEL<br>
data every time on a request, which does not seem optimal<br>
* The "add sel entry" does not really add a sel log, it adds an event<br>
entry to Redfish instead.<br>
* With above behavior, it basically has two separate types of logs,<br>
SEL logs that are from rsyslog, and redfish event logs that are done<br>
by "add sel entry". Thus the implementation seems to only support SELs<br>
for sensor threshold events, but not for discrete sensors.<br>
<br>
In bytedance we need a "full" SEL feature that supports both<br>
thresholds and discrete sensors.<br>
The whole solution is based on the DBus logging, but it involves<br>
different repos (ipmid, phosphor-logging, fault-monitor). Part of the<br>
implementation is upstreamed but some are internal for now.<br>
I would like to share the details when I have bandwidth :)<br>
<br>
-- <br>
BRs,<br>
Lei YU<br>
</blockquote></div>