Ard:
I think current region is 128 (1 << 7) bytes. But, I agree use exponential
bin sizes is better than linearly increasing with 128 bytes.
Your patch defines mPoolSizeTable as below. Its max value is 24128. When
Granularity is 64K, the request pool size that larger than 24128 will require
allocate Granularity size. Is it the expected result? Or expand to the value
nearly to 64K?
STATIC CONST UINT16 mPoolSizeTable[] = {
64, 128, 192, 320, 512, 832, 1344, 2176, 3520, 5696, 9216, 14912, 24128 //
append 39040, 63168?
};
Besides, could you verify this patch on the normal case that Granularity is
always 4K and collect the memory usage info?
Thanks
Liming
-----Original Message-----
From: Ard Biesheuvel [mailto:[email protected]]
Sent: Monday, February 09, 2015 12:51 AM
To: [email protected]; [email protected];
[email protected]; [email protected]; [email protected]; Justen,
Jordan L; Tian, Feng
Subject: [edk2] [PATCH 0/6] update pool allocator to better support 64 KB
runtime regions
This series implements an updated pool allocator that performs better in a
situation where the boot time and runtime allocation alignment is different,
and where either may be substantially larger than a single page.
Without these patches applied, the pool allocations (in bytes) that are served
from the bins are as follows (on AArch64-QEMU with Intel BDS using -kernel):
LoaderData used 3232 allocated 8192
BootSvData used 198872 allocated 319488
RuntSvData used 17592 allocated 32768
However, when increasing the granularity of the allocations for runtime regions
(patches #1 and #6 applied), it becomes apparent that the current code does not
cope well in the runtime case
LoaderData used 3424 allocated 4096
BootSvData used 198872 allocated 319488
RuntSvData used 17592 allocated 524288
This series attempts to address this by changing a couple of things in the pool
allocator:
- use exponential bin sizes rather than linearly increasing with 32 bytes
- if a bin is depleted, get a block from the next bin and split it up
With all patches applied, the numbers become
LoaderData used 3136 allocated 8192
BootSvData used 195344 allocated 270336
RuntSvData used 23136 allocated 65536
Note the final 'used' number has increased: this is most likely due to a pool
allocation of > 4 KB that was formerly served by a passthrough allocation
(i.e., a pool allocation that is backed directly by a call to AllocatePages
()), but is now served from one of the bins.
Ard Biesheuvel (6):
MdeModulePkg: use correct granularity when allocating pool pages
MdeModulePkg: improve scalability of memory pools
MdeModulePkg: use index to traverse free pool pages
MdeModulePkg: carve pool pages into the largest chunks possible
MdeModulePkg: serve allocations from higher-up bins if current bin is
empty
MdeModulePkg: use 64 KB granularity for runtime allocations on AArch64
MdeModulePkg/Core/Dxe/Mem/Imem.h | 9 +++
MdeModulePkg/Core/Dxe/Mem/Pool.c | 145 ++++++++++++++++++++++++++-------------
2 files changed, 107 insertions(+), 47 deletions(-)
--
1.8.3.2
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
