Request for Feedback on Releasing Reserved Memory Back to the Buddy Allocator

Request for Feedback on Releasing Reserved Memory Back to the Buddy Allocator

[moatasem zaaroura]

Dear Linux MM Community,

I am working on a system that requires reserving a known physical
memory region during the early boot phase and later releasing it back
to the kernel for general use. I would highly appreciate your feedback
on the approach I’ve taken, including any concerns, possible pitfalls,
or alternative recommendations.

== Problem Context ==

In my use case, the boot manager must copy data from flash to a known
DRAM location while the Linux kernel is still booting. This data is
then used in user space. After the user-space component finishes using
the data, I want to release this memory back to the system so it can
be utilized by the buddy allocator.

== My Solution ==

1. I reserved the memory region using a "reserved-memory" node in the
device tree with a fixed physical address and size.

2. This address is shared with the boot manager, which copies the
required data there before the kernel accesses it.

3. After the data is no longer needed (in user space), I expose a
sysfs interface to manually trigger the release of this reserved
memory back to the kernel.

== Freeing Logic ==

In the release function:
- I validate that the physical address (cache_addr) is page-aligned.
- I calculate the PFN using: pfn = PFN_DOWN(cache_addr);
- Then I loop over the pages:

        size_t i;
        struct page *page;
        unsigned long pfn;
        unsigned long number_of_pages = cache_size >> PAGE_SHIFT;

        if (cache_addr & (PAGE_SIZE - 1)) {
            pr_err("Physical address is not page-aligned\n");
            return;
        }

        pfn = PFN_DOWN(cache_addr);
        for (i = 0; i < number_of_pages; i++) {
            page = pfn_to_page(pfn);

            // Ensure the page is not part of the reserved pages
            if (PageReserved(page))
                free_reserved_page(page);
            pfn += 1;
        }

- I verified that the memory is successfully returned to the buddy
allocator by observing the increased number of free pages at
/proc/buddyinfo.

== What I'm Asking For ==

- Is this approach correct and safe under the current kernel memory
management design?
- Are there any problems I may have missed?
- Is there a better or more canonical way to achieve this?
- If the approach is sound, I believe this pattern may be useful for
others, especially in embedded systems. Would it make sense to
document or upstream a helper for this purpose?

I would be very grateful for your input and guidance.

Best regards,
Moatasem Zaaroura
OS Team – Mobileye

Re: Request for Feedback on Releasing Reserved Memory Back to the Buddy Allocator

[Harry Yoo]

On Wed, Apr 09, 2025 at 05:28:00PM +0300, moatasem zaaroura wrote:
> Dear Linux MM Community,
> 
> I am working on a system that requires reserving a known physical
> memory region during the early boot phase and later releasing it back
> to the kernel for general use. I would highly appreciate your feedback
> on the approach I’ve taken, including any concerns, possible pitfalls,
> or alternative recommendations.
> 
> == Problem Context ==
> 
> In my use case, the boot manager must copy data from flash to a known
> DRAM location while the Linux kernel is still booting. This data is
> then used in user space. After the user-space component finishes using
> the data, I want to release this memory back to the system so it can
> be utilized by the buddy allocator.
> 
> == My Solution ==
> 
> 1. I reserved the memory region using a "reserved-memory" node in the
> device tree with a fixed physical address and size.
> 
> 2. This address is shared with the boot manager, which copies the
> required data there before the kernel accesses it.
> 
> 3. After the data is no longer needed (in user space), I expose a
> sysfs interface to manually trigger the release of this reserved
> memory back to the kernel.
> 
> == Freeing Logic ==
> 
> In the release function:
> - I validate that the physical address (cache_addr) is page-aligned.
> - I calculate the PFN using: pfn = PFN_DOWN(cache_addr);
> - Then I loop over the pages:
> 
>         size_t i;
>         struct page *page;
>         unsigned long pfn;
>         unsigned long number_of_pages = cache_size >> PAGE_SHIFT;
> 
>         if (cache_addr & (PAGE_SIZE - 1)) {
>             pr_err("Physical address is not page-aligned\n");
>             return;
>         }
> 
>         pfn = PFN_DOWN(cache_addr);
>         for (i = 0; i < number_of_pages; i++) {
>             page = pfn_to_page(pfn);
> 
>             // Ensure the page is not part of the reserved pages

You mean "Ensure the page is the part of the reserved pages" ?

>             if (PageReserved(page))
>                 free_reserved_page(page);
>             pfn += 1;
>         }
> 
> - I verified that the memory is successfully returned to the buddy
> allocator by observing the increased number of free pages at
> /proc/buddyinfo.
> 
> == What I'm Asking For ==
> 
> - Is this approach correct and safe under the current kernel memory
> management design?
> - Are there any problems I may have missed?
> - Is there a better or more canonical way to achieve this?

I think memory hotplug [1] is an existing Linux approach to achieve this.

Does your reserved memory show up as a memory device in
/sys/devices/system/memory/memoryXXX?

Or does manual probing work for your memory?

[1] https://docs.kernel.org/admin-guide/mm/memory-hotplug.html#memory-hotplug-notifications

> - If the approach is sound, I believe this pattern may be useful for
> others, especially in embedded systems. Would it make sense to
> document or upstream a helper for this purpose?
> 
> I would be very grateful for your input and guidance.
> 
> Best regards,
> Moatasem Zaaroura
> OS Team – Mobileye
> 

-- 
Cheers,
Harry / Hyeonggon

Re: Request for Feedback on Releasing Reserved Memory Back to the Buddy Allocator

[David Hildenbrand]

On 14.04.25 22:25, Harry Yoo wrote:
> On Wed, Apr 09, 2025 at 05:28:00PM +0300, moatasem zaaroura wrote:
>> Dear Linux MM Community,
>>
>> I am working on a system that requires reserving a known physical
>> memory region during the early boot phase and later releasing it back
>> to the kernel for general use. I would highly appreciate your feedback
>> on the approach I’ve taken, including any concerns, possible pitfalls,
>> or alternative recommendations.
>>
>> == Problem Context ==
>>
>> In my use case, the boot manager must copy data from flash to a known
>> DRAM location while the Linux kernel is still booting. This data is
>> then used in user space. After the user-space component finishes using
>> the data, I want to release this memory back to the system so it can
>> be utilized by the buddy allocator.
>>
>> == My Solution ==
>>
>> 1. I reserved the memory region using a "reserved-memory" node in the
>> device tree with a fixed physical address and size.
>>
>> 2. This address is shared with the boot manager, which copies the
>> required data there before the kernel accesses it.
>>
>> 3. After the data is no longer needed (in user space), I expose a
>> sysfs interface to manually trigger the release of this reserved
>> memory back to the kernel.
>>
>> == Freeing Logic ==
>>
>> In the release function:
>> - I validate that the physical address (cache_addr) is page-aligned.
>> - I calculate the PFN using: pfn = PFN_DOWN(cache_addr);
>> - Then I loop over the pages:
>>
>>          size_t i;
>>          struct page *page;
>>          unsigned long pfn;
>>          unsigned long number_of_pages = cache_size >> PAGE_SHIFT;
>>
>>          if (cache_addr & (PAGE_SIZE - 1)) {
>>              pr_err("Physical address is not page-aligned\n");
>>              return;
>>          }
>>
>>          pfn = PFN_DOWN(cache_addr);
>>          for (i = 0; i < number_of_pages; i++) {
>>              page = pfn_to_page(pfn);
>>
>>              // Ensure the page is not part of the reserved pages
> 
> You mean "Ensure the page is the part of the reserved pages" ?
> 
>>              if (PageReserved(page))
>>                  free_reserved_page(page);
>>              pfn += 1;
>>          }
>>
>> - I verified that the memory is successfully returned to the buddy
>> allocator by observing the increased number of free pages at
>> /proc/buddyinfo.
>>
>> == What I'm Asking For ==
>>
>> - Is this approach correct and safe under the current kernel memory
>> management design?
>> - Are there any problems I may have missed?
>> - Is there a better or more canonical way to achieve this?
> 
> I think memory hotplug [1] is an existing Linux approach to achieve this.
> 
> Does your reserved memory show up as a memory device in
> /sys/devices/system/memory/memoryXXX?

It's a memblock allocation, so that memory would already be added to the 
system and hotplug does not apply.

-- 
Cheers,

David / dhildenb

Re: Request for Feedback on Releasing Reserved Memory Back to the Buddy Allocator

[David Hildenbrand]

On 09.04.25 16:28, moatasem zaaroura wrote:
> Dear Linux MM Community,
> 
> I am working on a system that requires reserving a known physical
> memory region during the early boot phase and later releasing it back
> to the kernel for general use. I would highly appreciate your feedback
> on the approach I’ve taken, including any concerns, possible pitfalls,
> or alternative recommendations.
> 
> == Problem Context ==
> 
> In my use case, the boot manager must copy data from flash to a known
> DRAM location while the Linux kernel is still booting. This data is
> then used in user space. After the user-space component finishes using
> the data, I want to release this memory back to the system so it can
> be utilized by the buddy allocator.
> 
> == My Solution ==
> 
> 1. I reserved the memory region using a "reserved-memory" node in the
> device tree with a fixed physical address and size.
> 
> 2. This address is shared with the boot manager, which copies the
> required data there before the kernel accesses it.
> 
> 3. After the data is no longer needed (in user space), I expose a
> sysfs interface to manually trigger the release of this reserved
> memory back to the kernel.
> 
> == Freeing Logic ==
> 
> In the release function:
> - I validate that the physical address (cache_addr) is page-aligned.
> - I calculate the PFN using: pfn = PFN_DOWN(cache_addr);
> - Then I loop over the pages:
> 
>          size_t i;
>          struct page *page;
>          unsigned long pfn;
>          unsigned long number_of_pages = cache_size >> PAGE_SHIFT;
> 
>          if (cache_addr & (PAGE_SIZE - 1)) {
>              pr_err("Physical address is not page-aligned\n");
>              return;
>          }
> 
>          pfn = PFN_DOWN(cache_addr);
>          for (i = 0; i < number_of_pages; i++) {
>              page = pfn_to_page(pfn);
> 
>              // Ensure the page is not part of the reserved pages
>              if (PageReserved(page))
>                  free_reserved_page(page);
>              pfn += 1;


Yeah, this is pretty basic freeing of memblock allocations.

reserve_mem_release_by_name does something close to that.

Which makes me wonder if the "reserved-memory" node you mention above is 
exactly what reserve_mem_release_by_name() is used for? "Release 
reserved memory region with a given name"

> 
> == What I'm Asking For ==
> 
> - Is this approach correct and safe under the current kernel memory
> management design?

Yes, that's what free_reserved_area/free_reserved_page is for: to free 
memblock allocations to the buddy.

> - Are there any problems I may have missed?

Not that I am aware.

> - Is there a better or more canonical way to achieve this?

See above. I would either expect that we already have a helper for this, 
or we should add one.

> - If the approach is sound, I believe this pattern may be useful for
> others, especially in embedded systems. Would it make sense to
> document or upstream a helper for this purpose?
> 

Yeah. I'm really curious if reserve_mem_release_by_name() is what you 
are looking for, or if it's dealing with "different reserved memory".

-- 
Cheers,

David / dhildenb