From: "Ni, Ray" <ray.ni@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
"lersek@redhat.com" <lersek@redhat.com>,
"Wu, Hao A" <hao.a.wu@intel.com>,
"rfc@edk2.groups.io" <rfc@edk2.groups.io>
Cc: "Dong, Eric" <eric.dong@intel.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>,
"Zeng, Star" <star.zeng@intel.com>
Subject: Re: [edk2-devel] [RFC][PATCH v1] UefiCpuPkg/MpInitLib DXE: Reduce AP status check interval
Date: Mon, 16 Mar 2020 01:37:45 +0000 [thread overview]
Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C49B8BF@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <6bf39348-1fcb-fd14-bc16-dd026ed200ad@redhat.com>
> The use case is valid, IMO. And the commit message is helpful.
>
> But I really think this constant should be PCD. Here's why I think a
> platform might want to control it:
>
> - The best (finest) possible resolution for timer events is platform
> dependent, IIUC. The duration of the "idle tick" is platform-specific.
> And, it likely makes no sense to set AP_CHECK_INTERVAL to a duration
> that's around, or under, what the arch timer resolution allows for.
>
> - In the other direction, CheckAndUpdateApsStatus() contains a loop that
> counts up to CpuMpData->CpuCount. In a very large system (hundreds or
> maybe thousands of APs) this function may have non-negligible cost.
>
> I suggest introducing a PCD for this (measured in msecs) and using 100
> msecs as the default.
Laszlo,
Adding a PCD means platform integrators need to consider which value to set.
Most of the time, they may just use the default PCD value.
Then, why not we add the PCD later when a real case is met?
Thanks,
Ray
next prev parent reply other threads:[~2020-03-16 1:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-13 13:22 [RFC][PATCH v1] UefiCpuPkg/MpInitLib DXE: Reduce AP status check interval Wu, Hao A
2020-03-13 19:17 ` Laszlo Ersek
2020-03-16 1:37 ` Ni, Ray [this message]
2020-03-23 12:00 ` [edk2-devel] " 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=734D49CCEBEEF84792F5B80ED585239D5C49B8BF@SHSMSX104.ccr.corp.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