On 3 March 2015 at 06:55, Gao, Liming <liming....@intel.com> wrote:
> 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.
>
Ah yes, you are quite right.
> 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?
> };
>
That would be possible, indeed. But it would make less likely that
large allocations would ever be freed again, so I opted for limiting
it at 24128. That way, if you allocate 32k, for instance, and free it
later, you will be guaranteed that it is freed. I don't have any
numbers to justify it, though.
> Besides, could you verify this patch on the normal case that Granularity is
> always 4K and collect the memory usage info?
>
Yes, I will
Regards,
Ard.
> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Monday, February 09, 2015 12:51 AM
> To: edk2-devel@lists.sourceforge.net; ler...@redhat.com;
> olivier.mar...@arm.com; roy.fr...@linaro.org; leif.lindh...@linaro.org;
> 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
> edk2-devel@lists.sourceforge.net
> 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
> edk2-devel@lists.sourceforge.net
> 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
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
