From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mx.groups.io with SMTP id smtpd.web10.266.1575263691635557650 for ; Sun, 01 Dec 2019 21:14:51 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: intel.com, ip: 134.134.136.126, mailfrom: ray.ni@intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2019 21:14:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.69,268,1571727600"; d="scan'208";a="200479555" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga007.jf.intel.com with ESMTP; 01 Dec 2019 21:14:50 -0800 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 1 Dec 2019 21:14:49 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.439.0; Sun, 1 Dec 2019 21:14:49 -0800 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.90]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.29]) with mapi id 14.03.0439.000; Mon, 2 Dec 2019 13:14:49 +0800 From: "Ni, Ray" To: Laszlo Ersek , "Dong, Eric" , "devel@edk2.groups.io" CC: "Gao, Liming" Subject: Re: [PATCH v2] UefiCpuPkg/PiSmmCpuDxeSmm: Avoid allocate Token every time. Thread-Topic: [PATCH v2] UefiCpuPkg/PiSmmCpuDxeSmm: Avoid allocate Token every time. Thread-Index: AQHVpfPKVAgOOmjvcUWB0nxhcTGlmaehWXBA///emgCABRgEkA== Date: Mon, 2 Dec 2019 05:14:49 +0000 Message-ID: <734D49CCEBEEF84792F5B80ED585239D5C38341C@SHSMSX104.ccr.corp.intel.com> References: <20191128061716.196-1-eric.dong@intel.com> <7ac1f712-5da3-e6b2-f24e-936feb81daa3@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C372368@SHSMSX104.ccr.corp.intel.com> <1f1dd740-420d-2074-dd7e-198b3b5386ad@redhat.com> In-Reply-To: <1f1dd740-420d-2074-dd7e-198b3b5386ad@redhat.com> Accept-Language: en-US, zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: 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 > > Laszlo, > > I agree with you to use to PCD for "token count per chunk". > > But I suggest the default value of that PCD can be at least 64. > > Reasons: > > 1. MM_MP is the new MP protocol in SMM environment and we expect > > all SMM code start to use the new protocol instead of the original > StartupThisAp > > service exposed through SMM System table. >=20 > If we consider the older SmmStartupThisAp() / MmStartupThisAp() member > functions, the situation is almost the same -- (almost) no callers. In > edk2, only SmmPeriodicSmiLib seems to call this SMST (MMST) API. In > edk2-platforms, MinPlatformPkg uses the lib class, and also calls > SmmStartupThisAp(). >=20 > I'm just saying that "all SMM code" using "the original StartupThisAp > service" in fact means a single open source platform. The benefit of MmMp is it introduces StartupAllAps service which is very useful in many core system. There are needs to call the new services in close source code. PI spec contains a more detailed description on the differences: * It is possible to invoke a procedure on multiple processors. * Supports blocking and non-blocking modes of operation. >=20 > > 2. A value of 1 is totally to disable the pre-allocating. >=20 > I disagree; with value 1, the InitializeDataForMmMp() function allocates > a new chunk, with room for 1 token. That occurs ahead of actually > needing the token, therefore it is a preallocation. >=20 > What you mean is that the chunking will not make a difference relative > to the current behavior, because every token creation/use will require a > new chunk allocation. Indeed. >=20 > But that doesn't change the fact that the first token will be allocated > prior to actually needing it, and if a platform never needs a token, > then the first chunk will just be there doing nothing. I agree 1 is different from disabling the pre-allocating. But 1 is not enough in a system that needs to use MmMp multiple times in a single SMI. >=20 > > I prefer this > > pre-allocating is activated by default given the reason #1. > > > > 64 * 32/64 (SPIN LOCK size) =3D 2KB/4KB is not a big size. >=20 > Would it be possible to *not* produce the MM MP protocol at all, if the > PCD were 0? Because in that case, the DEC default for the PCD could be > 64 (or any other value), and in OVMF we could set the PCD in the DSC > file to zero.=20 Back to your suggestion, I am a bit curious why you prefer to have a PCD to turn on/off MmMp instead of pre-allocating 2KB/4KB memory. Any PCD introduces a cost that future developers needs to understand the meaning of the PCD and know how to set the PCD. Thanks, Ray