All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Yoo <harry.yoo@oracle.com>
To: moatasem zaaroura <moatasem9626@gmail.com>
Cc: linux-mm@kvack.org, David Hildenbrand <david@redhat.com>
Subject: Re: Request for Feedback on Releasing Reserved Memory Back to the Buddy Allocator
Date: Tue, 15 Apr 2025 05:25:24 +0900	[thread overview]
Message-ID: <Z_1vNKAfuvRSTG8F@harry> (raw)
In-Reply-To: <CAL+YV0n-R-h82m7KT7XOYrjtkmyVW0AOh91_XFMqHH1fkRMsZQ@mail.gmail.com>

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


  reply	other threads:[~2025-04-14 20:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-09 14:28 Request for Feedback on Releasing Reserved Memory Back to the Buddy Allocator moatasem zaaroura
2025-04-14 20:25 ` Harry Yoo [this message]
2025-04-15 13:19   ` David Hildenbrand
2025-04-15 13:18 ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z_1vNKAfuvRSTG8F@harry \
    --to=harry.yoo@oracle.com \
    --cc=david@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=moatasem9626@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.