From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mx.groups.io with SMTP id smtpd.web12.59078.1584322670158996477 for ; Sun, 15 Mar 2020 18:37:50 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.20, mailfrom: ray.ni@intel.com) IronPort-SDR: /EJ8afBUANUld7RBTz0xKmAwmG+JiAf5W0z5QZCiRhYDRncxWB8ldKgHUBJ6F7CfKGWUTGbBVQ KOXhTZIFVZKw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2020 18:37:49 -0700 IronPort-SDR: TTKgM+kpoPjxSEq1durf+qopaqP666XktjZZOVgDsZz+e+LFPoO48Nx484nvMJvBl4eK0DYPw0 dz1FIqMKd+mQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,558,1574150400"; d="scan'208";a="233022136" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by orsmga007.jf.intel.com with ESMTP; 15 Mar 2020 18:37:49 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 15 Mar 2020 18:37:49 -0700 Received: from shsmsx107.ccr.corp.intel.com (10.239.4.96) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 15 Mar 2020 18:37:48 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.206]) by SHSMSX107.ccr.corp.intel.com ([169.254.9.232]) with mapi id 14.03.0439.000; Mon, 16 Mar 2020 09:37:46 +0800 From: "Ni, Ray" To: "devel@edk2.groups.io" , "lersek@redhat.com" , "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 Thread-Topic: [edk2-devel] [RFC][PATCH v1] UefiCpuPkg/MpInitLib DXE: Reduce AP status check interval Thread-Index: AQHV+Ww19KJJMagtC0Gp9oHY1yVHwKhKbtsA Date: Mon, 16 Mar 2020 01:37:45 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C49B8BF@SHSMSX104.ccr.corp.intel.com> References: <20200313132229.7628-1-hao.a.wu@intel.com> <6bf39348-1fcb-fd14-bc16-dd026ed200ad@redhat.com> In-Reply-To: <6bf39348-1fcb-fd14-bc16-dd026ed200ad@redhat.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Return-Path: ray.ni@intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > The use case is valid, IMO. And the commit message is helpful. >=20 > But I really think this constant should be PCD. Here's why I think a > platform might want to control it: >=20 > - 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. >=20 > - 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. >=20 > 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