I've been looking at this a bit. It appears that implementing PEI
FreePool in this way would require:
* Adding a new HOB type EFI_HOB_TYPE_FREE_POOL to PiHob.h
* Adding a new FreePool PEI service to PiPeiCis.h
* Implementing the service in PeiMain.c and MemoryServices.c
* Adding PeiServicesFreePool() to PeiServicesLib
* Modifying PeiMemoryAllocationLib to call PeiServicesFreePool() when
freeing EfiBootServicesData, while ignoring free requests for other
memory types
The last step is a bit problematic, since PeiMemoryAllocationLib
implements non-EfiBootServicesData pool allocations using
AllocatePages(). FreePool() doesn't take a MemoryType parameter, so it
just has to trust that it has been given a EfiBootServicesData buffer
which was allocated from the HOB list. If a caller tries to free
non-EfiBootServicesData memory, eg. memory allocated via
AllocateRuntimePool(), the PEI service will return an error.
PeiMemoryAllocationLib can ignore the error, since a failed free is
essentially a no-op, which is the traditional implementation of
FreePool() in PEI anyway.
Does that sound like an acceptable level of complexity and impact to the
specifications? I'd rather not start the code first process if there's
no chance it will go through.
An alternative would be to implement pool allocation and freeing
entirely in PeiMemoryAllocationLib, instead of adding a new PEI service.
If the code is too big, PeiMemoryAllocationLib could wrap a PPI. Then
we could have different implementations, either backed by the HOB list
like the current allocator, or backed by pages with a more sophisticated
allocator.
Brian
-------- Original Message --------
From: Vincent Zimmer [mailto:vincent.zim...@gmail.com]
Sent: Wednesday, June 22, 2022, 4:59 PM
To: devel@edk2.groups.io, brian.john...@hpe.com
Subject: [edk2-devel] Clarification of Memory management in PEI phase
sounds like a good idea. As a next step, perhaps a candidate activity
for
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Code-First-Process
in anticipation of future inclusion in PI?
Vincent
On Wed, Jun 22, 2022 at 2:41 PM Brian J. Johnson <brian.john...@hpe.com>
wrote:
Andrew,
Yes, adding a new HOB type to represent free pool would probably be the easiest.
Or we could write or borrow a traditional malloc() implementation, similar to
DXE's pool allocator, and back it with memory from AllocatePages(). That would
probably have better performance, and would avoid fragmenting the pool memory
when non-pool HOBs are added. It would probably be more code, though.
Brian J. Johnson
________________________________
From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, June 22, 2022, 3:54 PM
To: Brian J. Johnson <brian.john...@hpe.com>
Cc: devel@edk2.groups.io, ayushdevel1...@gmail.com
Subject: [edk2-devel] Clarification of Memory management in PEI phase
Brian,
I think all the PEI Allocate Pool does is make a HOB [1]. I don’t think we can
remove HOBs when memory is freed as that would change pointers to pool. It may
be possible to mark a region as free and allocate from that list batch 1st, and
just over allocate space if needed. It could be as simple as just adding a new
HOB type to represent free pool.
[1]
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Pei/Memory/MemoryServices.c#L878
Thanks,
Andrew Fish
On Jun 22, 2022, at 12:39 PM, Brian J. Johnson <brian.johnson@hpe.comwrote:
Sorry for the late response to this thread...
PEI has grown greatly in complexity, as Andrew pointed out. Do we (TianoCore
community) think it's time to add a real pool manager to PEI? There's getting
to be quite a bit of post-DRAM-initialization PEI code on some platforms. And
really, having a limited amount of pre-DRAM memory available is an even better
reason for having an effective pool allocator, so the memory can be freed and
reused.
FWIW we (HPE) needed to add a private pool allocator to manage memory for a
proprietary h/w initialization module which needs to run in post-DRAM PEI, and
depends on allocating and freeing memory in different phases of its operation.
Brian J. Johnson
--
Brian J. Johnson
Enterprise X86 Lab
Hewlett Packard Enterprise
brian.john...@hpe.com
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#91002): https://edk2.groups.io/g/devel/message/91002
Mute This Topic: https://groups.io/mt/92114859/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
