From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.120]) by mx.groups.io with SMTP id smtpd.web10.5565.1575011844763534327 for ; Thu, 28 Nov 2019 23:17:24 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PTB1E2r4; spf=pass (domain: redhat.com, ip: 205.139.110.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1575011843; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VAymZtVWu3Dw51Ilno1Xqzz+9pATRotjmWDs1beI/x8=; b=PTB1E2r49ng7l/AO76kgityfn20MkL+vhnvI5lb+p/4XUMMH7DYLBcpgj3kodqWK88VxqD 4D7AcguQDKz7L6K1j2ngRl0FJOpkkD10NRa/tje/MdVeqx+Y32VjFY3+HnR9KbtUDMdN7d cU49QCRM4lo/SaUqfQyV1yRHb9ZG/x8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-144-vhQBhWltPImdtg2038zXSQ-1; Fri, 29 Nov 2019 02:17:20 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0098510054E3; Fri, 29 Nov 2019 07:17:19 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-166.ams2.redhat.com [10.36.116.166]) by smtp.corp.redhat.com (Postfix) with ESMTP id EE3A15D9C5; Fri, 29 Nov 2019 07:17:17 +0000 (UTC) Subject: Re: [PATCH v2] UefiCpuPkg/PiSmmCpuDxeSmm: Avoid allocate Token every time. To: "Ni, Ray" , "Dong, Eric" , "devel@edk2.groups.io" Cc: "Gao, Liming" References: <20191128061716.196-1-eric.dong@intel.com> <7ac1f712-5da3-e6b2-f24e-936feb81daa3@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C372368@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <1f1dd740-420d-2074-dd7e-198b3b5386ad@redhat.com> Date: Fri, 29 Nov 2019 08:17:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5C372368@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-MC-Unique: vhQBhWltPImdtg2038zXSQ-1 X-Mimecast-Spam-Score: 0 Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 11/29/19 02:22, Ni, Ray wrote: >> >> I suggest that we introduce a new PCD for "token count per chunk", and >> set the default value to 1, in the DEC file. (And we should copy the PCD >> into a global variable, in InitializeDataForMmMp().) >> >> This way, if a platform suddenly starts consuming tokens, it will work >> (there will always be a single available token). If they want to improve >> performance (using a chunked allocation style), they can set the PCD as >> they see fit. >> > > 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. 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(). I'm just saying that "all SMM code" using "the original StartupThisAp service" in fact means a single open source platform. > 2. A value of 1 is totally to disable the pre-allocating. 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. 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. 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 prefer this > pre-allocating is activated by default given the reason #1. > > 64 * 32/64 (SPIN LOCK size) = 2KB/4KB is not a big size. 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. Thanks, Laszlo