On 10 February 2015 at 02:27, Tian, Feng <feng.t...@intel.com> wrote: > Ard, > > We are reviewing your patch and hope we can get back to you before PRC Spring > Festival:) >
Hello Feng, Any updates on this? Thank you, Ard. > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, February 09, 2015 00:51 > 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 > Cc: Ard Biesheuvel > Subject: [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
