Reducing expire time in propertiesChangedCallback
This code change is related to the code review,
https://gerrit.openbmc.org/c/openbmc/phosphor-led-manager/+/66774
Where “Phosphor LED Manager” app was waiting to read interface
value from DBus hosted by EntityManager to find out its system type.
It caused more delay in loading appropriate system JSON file, hence
“Phosphor LED Manager” app missing early faulty FRU notifications.
To fix this issue, reading system type from device tree is introduced.
For this, code reviewer asked to check what was causing delay in
EntityManager and asked to improve efficiency of EM if possible.
For this suggestion, tested EntityManager with varying delays in
propertiesChangedCallback api, ranging from 5 seconds to
500 milliseconds on IBM systems.
Observed improved performance in creating interfaces for matching
probes with a 500 millisecond delay.
Decided to retain the 500 millisecond delay to avoid altering the
system's behavior significantly. This delay should not impact
other systems. The choice of 500 milliseconds is arbitrary but based
on observed performance improvements.
Testing:
With the change observed EM is starting fine, observed no error on log
and publishes all its matched interfaces on DBus. And all other system
services are up and running on reboot.
Change-Id: I2e1528e408686d80476b9c834d6c2735dcadff22
Signed-off-by: Anupama B R <anupama.b.r1@ibm.com>
diff --git a/src/entity_manager.cpp b/src/entity_manager.cpp
index fb72d83..f76a6f5 100644
--- a/src/entity_manager.cpp
+++ b/src/entity_manager.cpp
@@ -1066,7 +1066,7 @@
instance++;
size_t count = instance;
- timer.expires_after(std::chrono::seconds(5));
+ timer.expires_after(std::chrono::milliseconds(500));
// setup an async wait as we normally get flooded with new requests
timer.async_wait([&systemConfiguration, &objServer,