From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.65; helo=mga03.intel.com; envelope-from=jordan.l.justen@intel.com; receiver=edk2-devel@lists.01.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BAFF421B00DC1 for ; Wed, 8 Nov 2017 22:51:49 -0800 (PST) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2017 22:55:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.44,368,1505804400"; d="scan'208";a="173681902" Received: from jwjarre1-mobl1.amr.corp.intel.com (HELO localhost) ([10.255.76.183]) by fmsmga005.fm.intel.com with ESMTP; 08 Nov 2017 22:55:50 -0800 MIME-Version: 1.0 To: "Ni, Ruiyu" , Laszlo Ersek Message-ID: <151021054953.14125.10727630216824816281@jljusten-skl> From: Jordan Justen In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BAB7B62@SHSMSX104.ccr.corp.intel.com> Cc: "Dong, Eric" , Ard Biesheuvel , "edk2-devel@lists.01.org" , "Yao, Jiewen" , "Kinney, Michael D" References: <20171012084810.148196-1-ruiyu.ni@intel.com> <20171012084810.148196-4-ruiyu.ni@intel.com> <03e369bb-77c4-0134-258f-bdae62cbc8c5@redhat.com> <151019243761.10467.634318081879242382@jljusten-skl> <734D49CCEBEEF84792F5B80ED585239D5BAB7B62@SHSMSX104.ccr.corp.intel.com> User-Agent: alot/0.6 Date: Wed, 08 Nov 2017 22:55:49 -0800 Subject: Re: [PATCH 3/4] UefiCpuPkg/MtrrLib: Update algorithm to calculate optimal settings X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 06:51:49 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2017-11-08 19:04:35, Ni, Ruiyu wrote: > Jordan, Laszlo, > = > I didn't realize that a platform may have less than 4-page stack > before memory is ready. If I was aware of that, I would change the > default scratch buffer size to 2 page, which should be enough too. This does not sound much better. I'm saying that the BASE library should only use at most a few hundred bytes of stack. Apparently the old algorithm did not use much memory, but perhaps was slow? Can we put it back in place for the BASE version of the library? Then, we can add a DXE specific version that uses a large buffer which it can allocate, and potentially free. -Jordan