diff mbox

[edk2] ArmVirtPkg: increase memory preallocations to reduce region count

Message ID 1433342954-15072-1-git-send-email-ard.biesheuvel@linaro.org
State New
Headers show

Commit Message

Ard Biesheuvel June 3, 2015, 2:49 p.m. UTC
This updates the sizes of the preallocated regions so that the number
of distinct regions that exists is minimal at the time we exit boot
services.

For a typical run of the ArmVirtQemu platform, we get the following
utilization numbers:

  Reserved  :              4 Pages (16,384 Bytes)
  LoaderCode:            210 Pages (860,160 Bytes)
  LoaderData:              0 Pages (0 Bytes)
  BS_Code   :            355 Pages (1,454,080 Bytes)
  BS_Data   :          6,807 Pages (27,881,472 Bytes)
  RT_Code   :            112 Pages (458,752 Bytes)
  RT_Data   :            288 Pages (1,179,648 Bytes)
  ACPI_Recl :             32 Pages (131,072 Bytes)
  ACPI_NVS  :              0 Pages (0 Bytes)
  MMIO      :         16,385 Pages (67,112,960 Bytes)
  MMIO_Port :              0 Pages (0 Bytes)
  PalCode   :              0 Pages (0 Bytes)
  Available :        123,264 Pages (504,889,344 Bytes)
              --------------
Total Memory:            511 MB (536,854,528 Bytes)

Strangely enough, the allocation count of 20,000 pages for BS_Data
does not result in those regions being merged. For BS_Code, RT_Code
and RT_Data, the increased preallocation results in the following
reduction in the number of regions.

   0x000040000000-0x00004000ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
-  0x000040010000-0x0000b66bbfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
-  0x0000b66bc000-0x0000b66d0fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
-  0x0000b66d1000-0x0000b6f6bfff [Loader Code        |   |  |  |  |   |WB|WT|WC|UC]
-  0x0000b6f6c000-0x0000b6f6ffff [Reserved           |   |  |  |  |   |WB|WT|WC|UC]*
-  0x0000b6f70000-0x0000b6f8ffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
-  0x0000b6f90000-0x0000b6faffff [ACPI Reclaim Memory|   |  |  |  |   |WB|WT|WC|UC]*
-  0x0000b6fb0000-0x0000b6fcffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
-  0x0000b6fd0000-0x0000b701ffff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
-  0x0000b7020000-0x0000b702ffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
-  0x0000b7030000-0x0000b70cffff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
-  0x0000b70d0000-0x0000b70dffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
+  0x000040010000-0x0000b680bfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
+  0x0000b680c000-0x0000b6820fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
+  0x0000b6821000-0x0000b70bbfff [Loader Code        |   |  |  |  |   |WB|WT|WC|UC]
+  0x0000b70bc000-0x0000b70bffff [Reserved           |   |  |  |  |   |WB|WT|WC|UC]*
+  0x0000b70c0000-0x0000b70dffff [ACPI Reclaim Memory|   |  |  |  |   |WB|WT|WC|UC]*
   0x0000b70e0000-0x0000b9f87fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
   0x0000b9f88000-0x0000bb921fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]
   0x0000bb922000-0x0000bb9bffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
   0x0000bb9c0000-0x0000bbbb0fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]
   0x0000bbbb1000-0x0000bbbeffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
   0x0000bbbf0000-0x0000bbf1ffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]
-  0x0000bbf20000-0x0000bedfffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
-  0x0000bee00000-0x0000bf71ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
-  0x0000bf720000-0x0000bf7ccfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
-  0x0000bf7cd000-0x0000bf92ffff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]
-  0x0000bf930000-0x0000bf93ffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
-  0x0000bf940000-0x0000bf95ffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
-  0x0000bf960000-0x0000bf97ffff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
+  0x0000bbf20000-0x0000bebfffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
+  0x0000bec00000-0x0000bf51ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
+  0x0000bf520000-0x0000bf65cfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
+  0x0000bf65d000-0x0000bf7bffff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]
+  0x0000bf7c0000-0x0000bf84ffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
+  0x0000bf850000-0x0000bf86ffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
+  0x0000bf870000-0x0000bf97ffff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
   0x0000bf980000-0x0000bf997fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
   0x0000bf998000-0x0000bf99afff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]
   0x0000bf99b000-0x0000bf9aefff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 ArmVirtPkg/ArmVirt.dsc.inc | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Ard Biesheuvel June 3, 2015, 4:14 p.m. UTC | #1
On 3 June 2015 at 17:40, Laszlo Ersek <lersek@redhat.com> wrote:
> On 06/03/15 16:49, Ard Biesheuvel wrote:
>> This updates the sizes of the preallocated regions so that the number
>> of distinct regions that exists is minimal at the time we exit boot
>> services.
>>
>> For a typical run of the ArmVirtQemu platform, we get the following
>> utilization numbers:
>>
>>   Reserved  :              4 Pages (16,384 Bytes)
>>   LoaderCode:            210 Pages (860,160 Bytes)
>>   LoaderData:              0 Pages (0 Bytes)
>>   BS_Code   :            355 Pages (1,454,080 Bytes)
>>   BS_Data   :          6,807 Pages (27,881,472 Bytes)
>>   RT_Code   :            112 Pages (458,752 Bytes)
>>   RT_Data   :            288 Pages (1,179,648 Bytes)
>>   ACPI_Recl :             32 Pages (131,072 Bytes)
>>   ACPI_NVS  :              0 Pages (0 Bytes)
>>   MMIO      :         16,385 Pages (67,112,960 Bytes)
>>   MMIO_Port :              0 Pages (0 Bytes)
>>   PalCode   :              0 Pages (0 Bytes)
>>   Available :        123,264 Pages (504,889,344 Bytes)
>>               --------------
>> Total Memory:            511 MB (536,854,528 Bytes)
>>
>> Strangely enough, the allocation count of 20,000 pages for BS_Data
>> does not result in those regions being merged. For BS_Code, RT_Code
>> and RT_Data, the increased preallocation results in the following
>> reduction in the number of regions.
>>
>>    0x000040000000-0x00004000ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>> -  0x000040010000-0x0000b66bbfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>> -  0x0000b66bc000-0x0000b66d0fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>> -  0x0000b66d1000-0x0000b6f6bfff [Loader Code        |   |  |  |  |   |WB|WT|WC|UC]
>> -  0x0000b6f6c000-0x0000b6f6ffff [Reserved           |   |  |  |  |   |WB|WT|WC|UC]*
>> -  0x0000b6f70000-0x0000b6f8ffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>> -  0x0000b6f90000-0x0000b6faffff [ACPI Reclaim Memory|   |  |  |  |   |WB|WT|WC|UC]*
>> -  0x0000b6fb0000-0x0000b6fcffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>> -  0x0000b6fd0000-0x0000b701ffff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>> -  0x0000b7020000-0x0000b702ffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>> -  0x0000b7030000-0x0000b70cffff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>> -  0x0000b70d0000-0x0000b70dffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>> +  0x000040010000-0x0000b680bfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>> +  0x0000b680c000-0x0000b6820fff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>> +  0x0000b6821000-0x0000b70bbfff [Loader Code        |   |  |  |  |   |WB|WT|WC|UC]
>> +  0x0000b70bc000-0x0000b70bffff [Reserved           |   |  |  |  |   |WB|WT|WC|UC]*
>> +  0x0000b70c0000-0x0000b70dffff [ACPI Reclaim Memory|   |  |  |  |   |WB|WT|WC|UC]*
>>    0x0000b70e0000-0x0000b9f87fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>>    0x0000b9f88000-0x0000bb921fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]
>>    0x0000bb922000-0x0000bb9bffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>>    0x0000bb9c0000-0x0000bbbb0fff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]
>>    0x0000bbbb1000-0x0000bbbeffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>>    0x0000bbbf0000-0x0000bbf1ffff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]
>> -  0x0000bbf20000-0x0000bedfffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>> -  0x0000bee00000-0x0000bf71ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>> -  0x0000bf720000-0x0000bf7ccfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>> -  0x0000bf7cd000-0x0000bf92ffff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]
>> -  0x0000bf930000-0x0000bf93ffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>> -  0x0000bf940000-0x0000bf95ffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>> -  0x0000bf960000-0x0000bf97ffff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>> +  0x0000bbf20000-0x0000bebfffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>> +  0x0000bec00000-0x0000bf51ffff [Loader Data        |   |  |  |  |   |WB|WT|WC|UC]
>> +  0x0000bf520000-0x0000bf65cfff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>> +  0x0000bf65d000-0x0000bf7bffff [Boot Code          |   |  |  |  |   |WB|WT|WC|UC]
>> +  0x0000bf7c0000-0x0000bf84ffff [Runtime Code       |RUN|  |  |  |   |WB|WT|WC|UC]*
>> +  0x0000bf850000-0x0000bf86ffff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>> +  0x0000bf870000-0x0000bf97ffff [Runtime Data       |RUN|  |  |  |   |WB|WT|WC|UC]*
>>    0x0000bf980000-0x0000bf997fff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>>    0x0000bf998000-0x0000bf99afff [Boot Data          |   |  |  |  |   |WB|WT|WC|UC]
>>    0x0000bf99b000-0x0000bf9aefff [Conventional Memory|   |  |  |  |   |WB|WT|WC|UC]
>
> Heh, this output was produced by kernel code that I wrote. (I've written
> negligible amounts of upstream kernel code.) Good way to sell me this
> patch! :)
>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>  ArmVirtPkg/ArmVirt.dsc.inc | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
>> index fd20ff39a068..08fb18a0c11a 100644
>> --- a/ArmVirtPkg/ArmVirt.dsc.inc
>> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
>> @@ -330,9 +330,9 @@
>>    gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0
>>    gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0
>>    gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0
>> -  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|50
>> -  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|20
>> -  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|400
>> +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|300
>> +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|150
>> +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|1000
>>    gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesData|20000
>>    gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|20
>>    gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData|0
>>
>
> Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Thanks, pushed as r17554
Ard Biesheuvel June 3, 2015, 5:08 p.m. UTC | #2
On 3 June 2015 at 19:03, Laszlo Ersek <lersek@redhat.com> wrote:
> On 06/03/15 18:14, Ard Biesheuvel wrote:
>
>> Thanks, pushed as r17554
>
> Congrats to your first (am I right?) SVN commit!
>

Indeed!

> A small tip (feel free to ignore it): since for edk2 patches, the
> tianocore contribution agreement is needed, it's useful to set up a
> commit message template. Something like:
>
> [commit]
>         template = /home/ardb/misc/tianocore.template
>
> where the referenced file would say:
>
> --------------
>
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> -----------------
>

Yes, I am using that already

> The "trick" I'm proposing here is that you include your S-o-b with the
> template as well, since you "should" have a template anyway. (Or else,
> pass --signoff to "git-commit".)
>

On other projects, I am used to doing 'git commit -s' to add the
signoff. I never rely on git-format-patch to do that.

> Additionally, ask git-format-patch not to generate your S-o-b's on the fly:
>
> [format]
>         signoff = false
>
> Your posted patches will look the same, but the difference will be that
> your commit messages themselves will include your signoffs; the S-o-b
> tags won't be generated *only* when formatting the patches.
>
> Why is this good? Because the resultant signoffs-in-commits will be
> consistent with patches that you apply from others (with git-am), and
> because this way you can add my R-b tag *after* your S-o-b, via rebasing.
>

I added it before deliberately, since the signoff that comes after it
then signifies that *I* was the one that added the R-b, not someone
that handled and signed off on the patch after me.

For instance, in kernel commits, you may see something like:

"""
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
"""

(https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/commit/8cf5e6dc8dd55d0f1ad46ab4046c3a8a51d2136d)

where it is clearly the maintainer that picked up the R-b from the
list, and not the author that added it.

> Just my two cents (in a wall of text, sorry), feel free to ignore.
>

No, let's discuss ... :-)

------------------------------------------------------------------------------
Ard Biesheuvel June 4, 2015, 6:07 a.m. UTC | #3
On 3 June 2015 at 19:39, Laszlo Ersek <lersek@redhat.com> wrote:
> On 06/03/15 19:08, Ard Biesheuvel wrote:
>> On 3 June 2015 at 19:03, Laszlo Ersek <lersek@redhat.com> wrote:
>>> On 06/03/15 18:14, Ard Biesheuvel wrote:
>>>
>>>> Thanks, pushed as r17554
>>>
>>> Congrats to your first (am I right?) SVN commit!
>>>
>>
>> Indeed!
>>
>>> A small tip (feel free to ignore it): since for edk2 patches, the
>>> tianocore contribution agreement is needed, it's useful to set up a
>>> commit message template. Something like:
>>>
>>> [commit]
>>>         template = /home/ardb/misc/tianocore.template
>>>
>>> where the referenced file would say:
>>>
>>> --------------
>>>
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> -----------------
>>>
>>
>> Yes, I am using that already
>>
>>> The "trick" I'm proposing here is that you include your S-o-b with the
>>> template as well, since you "should" have a template anyway. (Or else,
>>> pass --signoff to "git-commit".)
>>>
>>
>> On other projects, I am used to doing 'git commit -s' to add the
>> signoff. I never rely on git-format-patch to do that.
>>
>>> Additionally, ask git-format-patch not to generate your S-o-b's on the fly:
>>>
>>> [format]
>>>         signoff = false
>>>
>>> Your posted patches will look the same, but the difference will be that
>>> your commit messages themselves will include your signoffs; the S-o-b
>>> tags won't be generated *only* when formatting the patches.
>>>
>>> Why is this good? Because the resultant signoffs-in-commits will be
>>> consistent with patches that you apply from others (with git-am), and
>>> because this way you can add my R-b tag *after* your S-o-b, via rebasing.
>>>
>>
>> I added it before deliberately, since the signoff that comes after it
>> then signifies that *I* was the one that added the R-b, not someone
>> that handled and signed off on the patch after me.
>>
>> For instance, in kernel commits, you may see something like:
>>
>> """
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
>> Reviewed-by: Doug Anderson <dianders@chromium.org>
>> Signed-off-by: Kukjin Kim <kgene@kernel.org>
>> """
>>
>> (https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/commit/8cf5e6dc8dd55d0f1ad46ab4046c3a8a51d2136d)
>>
>> where it is clearly the maintainer that picked up the R-b from the
>> list, and not the author that added it.
>>
>>> Just my two cents (in a wall of text, sorry), feel free to ignore.
>>>
>>
>> No, let's discuss ... :-)
>>
>
> Haha, okay :)
>
> Since in this case you are both original author and maintainer, I think
> you should add your Signed-off-by both before and after my Reviewed-by,
> in essence taking both Javier's and Kukjin's roles. /deadpan
>
> In earnest tho, using your earlier (pre-maintainership) patches as an
> example, let's say you posted a patch (first S-o-b), Olivier reviewed it
> (R-b after first S-o-b), and (assume) I would apply it (second S-o-b,
> presumably). In this case however I would simply not add my S-o-b,
> because I had absolutely no input into it.

In the kernel, you *must* add your S-o-b if you are on the patch
delivery path (unless the patch gets merged from a pull request)

> Unless I forwarded that patch
> (via formatting and posting it) or expected someone to pull my tree,
> there would be no reason to add my S-o-b just for committing.
>
> Anyway, I shan't obsess about this again ;)
>

Good.

------------------------------------------------------------------------------
diff mbox

Patch

diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index fd20ff39a068..08fb18a0c11a 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -330,9 +330,9 @@ 
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0
-  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|50
-  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|20
-  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|400
+  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|300
+  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|150
+  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|1000
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesData|20000
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|20
   gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData|0