Hi Sugosh, On Mon, 8 Jul 2024 at 15:35, Tom Rini <tr...@konsulko.com> wrote: > > On Thu, Jul 04, 2024 at 01:04:56PM +0530, Sughosh Ganu wrote:
I don't believe coherent is the right word here. Perhaps 'more persistent' is better? > > > The aim of this patch series is to fix the current state of > > incoherence between modules when it comes to memory usage. The primary > > issue that this series is trying to fix is that the EFI memory module > > which is responsible for allocating and freeing memory, does not have > > any visibility of the memory that is being used by the LMB > > module. This is further complicated by the fact that the LMB > > allocations are caller specific -- the LMB memory map is not global > > nor persistent. This means that the memory "allocated" by the LMB > > module might be relevant only for a given function. Hence one of the > > requirements for making the memory usage visible across modules is to > > make LMB allocations persistent and global, and then have means to > > communicate the use of memory across modules. > > > > The first set of patches in this series work on making the LMB memory > > map persistent and global. This is being done keeping in mind the > > usage of LMB memory by platforms where the same memory region can be > > used to load multiple different images. What is not allowed is to > > overwrite memory that has been allocated by the other module, > > currently the EFI memory module. This is being achieved by introducing > > a new flag, LMB_NOOVERWRITE, which represents memory which cannot be > > re-requested once allocated. > > > > A review comment on the earlier version was to do away with the static > > arrays for the LMB lists of free and used memory. This version > > uses the alloced list data structure for the LMB lists. > > > > The second set of patches are making changes to the EFI memory module > > to make use of the LMB functions to allocate and free memory. A > > *_flags() version of LMB API's has been introduced for the same. The > > earlier version was using notification mechanism from both LMB and EFI > > modules to maintain memory coherence. This version makes use of the > > LMB API functions for the memory allocations. This is based on review > > comments of EFI maintainers. > > Please re-work so that the series is bisectable. For example > xilinx_zynqmp_r5 fails that check currently. And I found that looking in > to why it grows by ~1500 bytes overall. This likely is due to > CONFIG_EFI_LOADER=n and so while the case where EFI_LOADER is enabled > tends to be a size win (reduction) or wash we need to look at the > CONFIG_EFI_LOADER=n case more. The alist code will be a little growth > and that's fine enough. But realloc and do_bdinfo are the two big > growths at the top, in this case. > > -- > Tom Regards, Simon
