From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 2A7CA82244 for ; Tue, 21 Feb 2017 17:48:04 -0800 (PST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2017 17:48:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,191,1484035200"; d="scan'208";a="60952962" Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by orsmga004.jf.intel.com with ESMTP; 21 Feb 2017 17:48:03 -0800 Received: from orsmsx161.amr.corp.intel.com (10.22.240.84) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 21 Feb 2017 17:48:02 -0800 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.30]) by ORSMSX161.amr.corp.intel.com ([169.254.4.71]) with mapi id 14.03.0248.002; Tue, 21 Feb 2017 17:48:02 -0800 From: "Kinney, Michael D" To: "Justen, Jordan L" , "Yao, Jiewen" , Laszlo Ersek , edk2-devel-01 , "Kinney, Michael D" CC: "Ni, Ruiyu" , Andrew Fish , "Ard Biesheuvel" Thread-Topic: [edk2] memory type information HOB / UEFI memmap defrag Thread-Index: AQHSjFaVM5qdO2/qNEKDdvxGfGqYVaF0t7EAgAAMiQD//328MA== Date: Wed, 22 Feb 2017 01:48:02 +0000 Message-ID: References: <74D8A39837DF1E4DA445A8C0B3885C503A8F2DE0@shsmsx102.ccr.corp.intel.com> <148772709277.12591.2606094062546040536@jljusten-ivb> In-Reply-To: <148772709277.12591.2606094062546040536@jljusten-ivb> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZmVhODZiOTAtYmMyNC00NWVlLTkwYTUtM2U0ZWRjMjYzYTAyIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjZrRGZLZ2UrMVNDc3hFaEtnXC8wU0txS0ErbndicmtTUXJNZk92cFBuNWVRPSJ9 x-originating-ip: [10.22.254.138] MIME-Version: 1.0 Subject: Re: memory type information HOB / UEFI memmap defrag X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 01:48:04 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jordan, The usage of EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData may vary from boot to boot, especially if the shell or other applications are run or different OSes are booted. A change in the bin size causes extra variable writes and potentially extra reboots. Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Jo= rdan Justen > Sent: Tuesday, February 21, 2017 5:32 PM > To: Yao, Jiewen ; Laszlo Ersek ;= edk2-devel- > 01 > Cc: Ni, Ruiyu ; Andrew Fish ; Ard Bi= esheuvel > > Subject: Re: [edk2] memory type information HOB / UEFI memmap defrag >=20 > On 2017-02-21 16:46:40, Yao, Jiewen wrote: > > HI Laszlo > > > > The purpose of this table to put OS consumed memory together to avoid S= 4 resume > > issue. EfiLoaderCode/ EfiBootServicesCode/ EfiBootServicesData are not = used by > > OS. There is no need to put them here. > > > > I suggest we remove EfiLoaderCode/ EfiBootServicesCode/ EfiBootServices= Data to > > avoid confusing. > > >=20 > Is there any other advantage to removing them? >=20 > I guess it would be easy enough to re-add them, but I don't think we > need to move away from supporting S4. While I agree that S4 should not > be a big priority, I'd prefer that we try to support it at some point. >=20 > -Jordan >=20 > > > > > + { EfiReservedMemoryType, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 2= 02) }, > > > + { EfiLoaderCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 14= 39) }, > > > + { EfiBootServicesCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 59= 80) }, > > > + { EfiBootServicesData, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 416= 43) }, > > > + { EfiRuntimeServicesCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 10= 25) }, > > > + { EfiRuntimeServicesData, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 36= 29) }, > > > + { EfiACPIReclaimMemory, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * = 36) }, > > > + { EfiACPIMemoryNVS, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 13= 01) }, > > > + { EfiMaxMemoryType, 0 = } > > > > > > > > Thank you > > > > Yao Jiewen > > > > > > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of = Laszlo > > Ersek > > Sent: Tuesday, February 21, 2017 11:24 PM > > To: edk2-devel-01 > > Cc: Ni, Ruiyu ; Justen, Jordan L > > ; Andrew Fish ; Ard Biesheu= vel > > > > Subject: [edk2] memory type information HOB / UEFI memmap defrag > > > > > > > > Hi, > > > > the UEFI memmap under OVMF is getting very fragmented, I'm now counting > > ~80 entries in it, under various circumstances. > > > > I recall that a platform's PlatformPei can "prime" the DXE/UEFI memory > > allocation system (not the GCD services) for various memory types, by > > producing a memory type information HOB. > > > > My vague understanding is that BDS will in turn check if the actual > > allocations fit in the allotments from the HOB, and if not, it will try > > to feed back the increased amount to PEI, for the next boot. > > > > As far as I understand, this requires the VariablePei (read only driver= ) > > for a platform (so that its PlatformPei can read the info from BDS, and > > produce the HOB accordingly). Some questions: > > > > - how big is VariablePei in binary form? > > - does it depend on permanent RAM being installed / discovered? > > - If so, is that dependency implemented with a static DEPEX, or with a > > callback? > > > > Further questions: > > - what is the variable (GUID and Name) that BDS uses for this > > information? > > - What is the format of the variable? > > - Does the logic depend on particular boot modes? OVMF only supports tw= o > > boot modes, BOOT_WITH_FULL_CONFIGURATION and BOOT_ON_S3_RESUME. > > > > In OVMF we currently use a static array for populating the HOB (see > > "mDefaultMemoryTypeInformation" in "PlatformPei/Platform.c"). If making > > it all dynamic is easy, I think I'd like to do it (sometime later). > > > > If, however, it would require us to up-end OVMF's PlatformPei, then I > > think it's not worth it; we can just bump the values in > > "mDefaultMemoryTypeInformation" suitably. > > > > Some examples I consider as up-ending OVMF's PlatformPei: > > > > (1) If VariablePei needs permanent RAM with a hard DEPEX. In OVMF, > > permanent RAM is installed by PlatformPei (thereby potentially > > unblocking VariablePei's dispatch); however, it is also PlatformPei > > that would require the r/o variable service to work, because > > PlatformPei produces the memory type information HOB. So, such a > > DEPEX in VariablePei would require splitting up PlatformPei, which > > makes the dynamism totally not worth it. > > > > *Maybe* we could add a callback for when the variable service PPI i= s > > installed. Dunno. > > > > (2) Supporting a third boot mode beyond BOOT_WITH_FULL_CONFIGURATION an= d > > BOOT_ON_S3_RESUME. Not even worth the audit of current boot mode > > checks. > > > > Further remarks: > > > > - OVMF doesn't care about supporting S4 at the moment, and I personally > > have no plans to work on that. (I'm saying this because I vaguely > > recall that the memory type info HOB is related to S4 resume, so an > > argument could perhaps be made, "this could enable S4 for OVMF". > > Personally, I'm not interested. Still carrying the scars of S3.) > > > > - I actually tried to bump the values in "mDefaultMemoryTypeInformation= " > > quite a few months back, but the benefits I saw were negligible. I wa= s > > left confused about the memory type info HOB, and that was the reason > > I didn't ultimately post any patch (and why I stopped pursuing this > > question). For reference, this was the patch: > > > > > commit b357e8d88c0304ea2b31aefafe53d06c9769fb78 > > > Author: Laszlo Ersek > > > Date: Thu Sep 17 16:18:46 2015 +0200 > > > > > > OvmfPkg: PlatformPei: decrease memmap fragmentation > > > > > > Inspired by ArmVirtPkg commit c199315 ("ArmVirtPkg: increase memo= ry > > > preallocations to reduce region count"), I checked the number of = entries > > > in the UEFI memory map, as dumped by the UEFI shell's MEMMAP comm= and, and > > > by the Linux kernel. The number of entries is quite high, about 5= 0-55. > > > > > > I calculated the new preallocations as follows: > > > - added 15% to each byte count usage reported by the MEMMAP comma= nd, for > > > some future-proofing, > > > - expressed the result in kilobytes (both pages and byte counts a= re hard > > > to read), > > > - just for our information, I calculated the ratio between the ne= w > > > preallocation and the old one. > > > > > > For example, the UEFI shell reported 44 pages (180224 bytes) of r= eserved > > > memory usage. The new preallocation, expressed in kilobytes, is > > > trunc(180224 * 1.15 / 1024) =3D 202. This preallocation is approx= . 12.62 > > > times the previous preallocation (which was 4 pages, ie. 16384 by= tes). > > > > > > Here's the full table: > > > > > > memory type pages from bytes from new KB factor of former > > > MEMMAP cmd MEMMAP cmd prealloc prealloc > > > ----------- ---------- ---------- -------- ---------------- > > > Reserved 44 180224 202 12.62 > > > LoaderCode 313 1282048 1439 n/a > > > BS_Code 1300 5324800 5980 3.89 > > > BS_Data 9053 37081088 41643 2.71 > > > RT_Code 223 913408 1025 5.33 > > > RT_Data 789 3231744 3629 25.20 > > > ACPI_Recl 8 32768 36 1.12 > > > ACPI_NVS 283 1159168 1301 81.31 > > > > > > ... Unfortunately, when the patch is applied, the memory map rema= ins > > > fragmented; > > mostly due to small unused Conventional Memory entries between > > > other types of allocations. The entry count doesn't go below 40. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > > Signed-off-by: Laszlo Ersek > > > > > > diff --git a/OvmfPkg/PlatformPei/Platform.c b/OvmfPkg/PlatformPei/Pla= tform.c > > > index a6d961673d3a..38abf3811600 100644 > > > --- a/OvmfPkg/PlatformPei/Platform.c > > > +++ b/OvmfPkg/PlatformPei/Platform.c > > > @@ -41,14 +41,15 @@ > > > #include "Cmos.h" > > > > > > EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] =3D { > > > - { EfiACPIMemoryNVS, 0x004 }, > > > - { EfiACPIReclaimMemory, 0x008 }, > > > - { EfiReservedMemoryType, 0x004 }, > > > - { EfiRuntimeServicesData, 0x024 }, > > > - { EfiRuntimeServicesCode, 0x030 }, > > > - { EfiBootServicesCode, 0x180 }, > > > - { EfiBootServicesData, 0xF00 }, > > > - { EfiMaxMemoryType, 0x000 } > > > + { EfiReservedMemoryType, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 2= 02) }, > > > + { EfiLoaderCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 14= 39) }, > > > + { EfiBootServicesCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 59= 80) }, > > > + { EfiBootServicesData, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 416= 43) }, > > > + { EfiRuntimeServicesCode, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 10= 25) }, > > > + { EfiRuntimeServicesData, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 36= 29) }, > > > + { EfiACPIReclaimMemory, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * = 36) }, > > > + { EfiACPIMemoryNVS, EFI_SIZE_TO_PAGES ((UINTN)SIZE_1KB * 13= 01) }, > > > + { EfiMaxMemoryType, 0 = } > > > }; > > > > > > > > > > As you can see in the commit message, at that time the patch only > > managed to decrease the number of memmap entries from ~55 to ~40, which > > I found "meh". I figured I'd ask again, because now I'm seeing about 80 > > entries in the memmap. (I wonder if that is related to OVMF's recently > > increased ACPI S3 boot script usage!) > > > > Thanks, > > Laszlo > > > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel