From: Jiaqing Zhao <jiaqing.zhao@linux.intel.com>
To: Joseph Reynolds <jrey@linux.ibm.com>, openbmc@lists.ozlabs.org
Cc: apparao.puli@linux.intel.com, richard.marian.thomaiyar@linux.intel.com
Subject: Re: service-config-manager performance issue
Date: Tue, 22 Feb 2022 12:06:32 +0800 [thread overview]
Message-ID: <72521bb0-7a92-e80a-adf9-72edd1271e50@linux.intel.com> (raw)
In-Reply-To: <762e2959-ddb1-c075-a581-756cc4c9d791@linux.ibm.com>
On 2022-02-22 04:00, Joseph Reynolds wrote:
> On 2/21/22 6:41 AM, Jiaqing Zhao wrote:
>> Hi, all
>>
>> When updating service status with service-config-manager, it always takes ~15s for the new status to be applied, which is much longer than it should be.
>>
>> By inspecting the code, I found there is a 15s wait before updating service status in ServiceConfig::startServiceRestartTimer(). (https://github.com/openbmc/service-config-manager/blob/f2744893b77b9dd8903bb13113f4c3ef62c18f04/src/srvcfg_manager.cpp#L382)
>>
>> The 15s-wait is added at first in commit 0084047 (https://github.com/openbmc/service-config-manager/commit/0084047d008fd0ac36f09a232f67ff2fc5314b53).
>
> Here at IBM we are seeing the same thing. It looks like that code (https://github.com/openbmc/service-config-manager/blob/master/src/srvcfg_manager.cpp - ServiceConfig::startServiceRestartTimer) was part of the initial commit. I wonder if the problem is caused by a bug in that code. (But I am not familiar with the code, and I don't have time to look at it now.) Is the intention to reload the systemd units but give up after 15 seconds?
>
> Joseph
>
I think the author intends to execute systemd operations with a 15s timeout. But seems he misused boost::asio::steady_timer. The boost doc (https://www.boost.org/doc/libs/1_78_0/doc/html/boost_asio/reference/steady_timer.html) says the function in async_wait() is called when the timer has expired. So the code in service-config-manager actually calls the apply config function after asynchronously waited for 15s.
I cannot find out the proper a way to set a 15s time limit for the operation. Maybe we can set a max wait rounds of executing a systemd job in systemdUnitAction()? Currently it waits infinitely in ~20ms interval.
Jiaqing
>> I've tested service-config-manager works as expected with the wait removed, and it only takes ~1s for the settings being applied, shall we remove it? And I'd like to ask what is the purpose of this wait to double confirm if removing it will bring any side effect.
>>
>> Thanks,
>> Jiaqing
>
next prev parent reply other threads:[~2022-02-22 4:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-21 12:41 service-config-manager performance issue Jiaqing Zhao
2022-02-21 20:00 ` Joseph Reynolds
2022-02-22 4:06 ` Jiaqing Zhao [this message]
2022-03-07 9:25 ` Jiaqing Zhao
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=72521bb0-7a92-e80a-adf9-72edd1271e50@linux.intel.com \
--to=jiaqing.zhao@linux.intel.com \
--cc=apparao.puli@linux.intel.com \
--cc=jrey@linux.ibm.com \
--cc=openbmc@lists.ozlabs.org \
--cc=richard.marian.thomaiyar@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.