From: "Wu, Hao A" <hao.a.wu@intel.com>
To: devel@edk2.groups.io, rfc@edk2.groups.io
Cc: Hao A Wu <hao.a.wu@intel.com>, Eric Dong <eric.dong@intel.com>,
Ray Ni <ray.ni@intel.com>, Laszlo Ersek <lersek@redhat.com>,
Michael D Kinney <michael.d.kinney@intel.com>,
Star Zeng <star.zeng@intel.com>
Subject: [RFC][PATCH v1] UefiCpuPkg/MpInitLib DXE: Reduce AP status check interval
Date: Fri, 13 Mar 2020 21:22:29 +0800 [thread overview]
Message-ID: <20200313132229.7628-1-hao.a.wu@intel.com> (raw)
This commit will reduce the interval of the AP status check event from 100
milliseconds to 10 milliseconds.
(I searched the history of the 100ms interval, it seems no comment or log
message was mentioned for the choice of this value. Looks like the value
is selected by experience.)
The purpose is to reduce the response time when the BSP calls below
EFI_MP_SERVICES_PROTOCOL services in a non-blocking manner:
* StartupAllAPs()
* StartupThisAP()
Reducing the check interval will benefit the performance for the case when
the BSP uses WaitForEvent() or uses CheckEvent() in a loop to wait for
AP(s) to complete the task, especially when the task can be finished
considerably fast on AP(s).
An example is within function CpuFeaturesInitialize() under
UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.c,
where BSP will perform the same task with APs and requires all the
processors to finish the task before BSP proceeds to its next task.
Impact:
A. The impact is minimal when there is no non-blocking calls of the
StartupAllAPs/StartupThisAp MP services, because the check function
CheckAndUpdateApsStatus() will return directly when there is no
registered wait event (i.e. no non-blocking request).
B. There will be a performance tradeoff when BSP continues to proceed
other tasks after submitting a non-blocking StartupAllAPs/StartupThisAP
request. If the AP status check takes a good portion of the shortened
interval, BSP will have less time slice working on its own task before
all the APs complete their tasks.
My investigation for Impact B is that it is a rare scenario in the edk2
code base.
Unitests:
A. OS boot successfully.
B. System (with 24 threads) boot time reduced. Almost all the saved time
comes from the above-mentioned case in CpuFeaturesInitialize().
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
---
UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
index a987c32109..9ba886e8ed 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
@@ -15,7 +15,7 @@
#include <Protocol/Timer.h>
-#define AP_CHECK_INTERVAL (EFI_TIMER_PERIOD_MILLISECONDS (100))
+#define AP_CHECK_INTERVAL (EFI_TIMER_PERIOD_MILLISECONDS (10))
#define AP_SAFE_STACK_SIZE 128
CPU_MP_DATA *mCpuMpData = NULL;
--
2.12.0.windows.1
next reply other threads:[~2020-03-13 13:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-13 13:22 Wu, Hao A [this message]
2020-03-13 19:17 ` [RFC][PATCH v1] UefiCpuPkg/MpInitLib DXE: Reduce AP status check interval Laszlo Ersek
2020-03-16 1:37 ` [edk2-devel] " Ni, Ray
2020-03-23 12:00 ` Laszlo Ersek
2020-03-23 14:37 ` Ni, Ray
2020-03-23 16:38 ` Brian J. Johnson
2020-03-24 0:32 ` Wu, Hao A
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-list 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=20200313132229.7628-1-hao.a.wu@intel.com \
--to=devel@edk2.groups.io \
/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