Re: [edk2-devel] [RFC][PATCH v1] UefiCpuPkg/MpInitLib DXE: Reduce AP status check interval

["Wu, Hao A" <hao.a.wu@intel.com>]

> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Brian
> J. Johnson
> Sent: Tuesday, March 24, 2020 12:39 AM
> To: devel@edk2.groups.io; Ni, Ray; Laszlo Ersek; Wu, Hao A;
> rfc@edk2.groups.io
> Cc: Dong, Eric; Kinney, Michael D; Zeng, Star
> Subject: Re: [edk2-devel] [RFC][PATCH v1] UefiCpuPkg/MpInitLib DXE: Reduce
> AP status check interval
> 
> On 3/23/20 9:37 AM, Ni, Ray wrote:
> >>> 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?
> >>
> >> The patch changes existent behavior; it is not for a newly introduced
> >> feature.
> >>
> >> Because most platforms are not in the edk2 tree, we don't know what
> >> platforms could be regressed by increasing the polling frequency
> >> tenfold. (And remember that the polling action has O(n) cost, where "n"
> >> is the logical processor count.)
> >>
> >> Under your suggestion, the expression "real case is met" amounts to
> >> "someone reports a regression" (possibly after the next stable tag,
> >> even). I don't think that's a good idea.
> >> In particular, the patch is motivated by RegisterCpuFeaturesLib -- the
> >> CpuFeaturesInitialize() function -- on some platform(s) that Hao uses.
> >> But there are platforms that don't use RegisterCpuFeaturesLib, and still
> >> use MpInitLib.
> >
> > OK. I agree with your suggestion.
> 
> Thank you.  I agree with Laszlo:  MP initialization is tricky to scale,
> and platform dependent.  My group builds real machines with thousands of
> APs, and we have had to do various tweaks to the MP init. code.  Having
> a PCD to adjust this timeout will be very useful.


Thanks all for the feedbacks. Please grant me some time to prepare a new
version of the patch.

Best Regards,
Hao Wu


> 
> Thanks,
> --
> Brian J. Johnson
> Enterprise X86 Lab
> 
> Hewlett Packard Enterprise
> brian.johnson@hpe.com
> 
> 
>