Re: [RFC PATCH v3 2/2] mm: Separate different types of allocations into different regions

[Daniel Kiper]

On Sat, Oct 15, 2022 at 11:00:35AM +0200, Patrick Steinhardt wrote:
> On Thu, Oct 13, 2022 at 09:29:19AM +0800, Zhang Boyang wrote:
> > This patch add type infomation to heap regions. Currently there are four
> > types: GRUB_MM_SIZE_SMALL, GRUB_MM_SIZE_LARGE, GRUB_MM_CLASS_DATA,
> > GRUB_MM_CLASS_MODULE. Each heap region can have its own mask of
> > acceptable memory allocation types.
> >
> > The GRUB_MM_SIZE_* types denotes the relative size of an allocation.
> > Allocations lesser than GRUB_MM_GROW_SMALL belong to GRUB_MM_SIZE_SMALL,
> > otherwise they belong to GRUB_MM_SIZE_LARGE. Thus small and large chunks
> > can be separated into different heaps. This might help reduce heap
> > fragmentation.
> >
> > The GRUB_MM_CLASS_* types denotes whether an allocation is a module
> > segment. Module segments are allocated with GRUB_MM_CLASS_MODULE flag
> > set. Plain data chunks (and module metadata) are allocated with
> > GRUB_MM_CLASS_DATA flag set. Thus module segments and plain data chunks
> > can be separated into different heaps.
> >
> > On platforms with dynamic heap growth support, when heap space is
> > exhausted, a new region will be allocated from firmware. The new region
> > has same type flags as the allocation request itself. The size of new
> > region will be (size + align + GRUB_MM_MAX_COST) for GRUB_MM_SIZE_LARGE
> > requests, and (GRUB_MM_GROW_SMALL + GRUB_MM_MAX_COST) for
> > GRUB_MM_SIZE_SMALL requests, with GRUB_MM_MAX_COST denotes the extra
> > region management cost.
> >
> > On platforms without dynamic heap growth support, default heap will be
> > created with GRUB_MM_TYPE_ALL, so any type of allocation can be
> > fulfilled by default heap.
>
> I wonder whether we can again split this patch up into at least two
> parts: the first one that starts to round memory allocations, and then
> the second one to introduce memory types. The former would likely not be
> all that controversial. So by splitting this patch up we can already
> land the two patches to reorder disk cache invalidation and round
> requests, both of which should provide immediate benefit to users.
>
> The introduction of memory request types can then be discussed
> separately.

Yeah, I agree. Though first of all I would prefer fully understand all
pros and cons of memory request types in the bootloader. At this point
I would be more than happy if we simplify memory allocator/relocator than
add more futures to it. I think the bootloader does not need complicated
allocators covering all corner cases due to its quite short live time.
I prefer something which is simple and reliable. And probably fast...

Daniel