On Tue, Apr 01, 2025 at 11:11:59AM -0400, Steven Rostedt wrote: > On Tue, 1 Apr 2025 12:56:31 +0300 > Mike Rapoport <[email protected]> wrote: > > > > For example, using "mem=" on the kernel command line will literally > > > limit the amount of RAM the kernel will use, and in doing so will > > > limit the page allocations too. > > > > And using memmap=m$n on x86 creates a hole in System RAM that does not have > > neither struct page nor kernel mappings and it is never considered RAM > > anywhere in mm. > > Hmm, when that is used, then we had better not "free" the buffer. > > > > > > IOW, all of these kernel command line things are *subtle*. > > > > > > Don't mis-use them by then making assumptions about how they work > > > today (or how they will work tomorrow). > > > > I'd say it's better not to use them at all. They cause weirdness in memory > > layout and also they are inconsistent in how architectures implement them. > > > > > > Mike can correct me if I'm wrong, but the memory that was stolen was > > > > actual > > > > memory returned by the system (E820 in x86). It reserves the memory > > > > before > > > > the memory allocation reserves this memory. So what reserve_mem returns > > > > is > > > > valid memory that can be used by memory allocator, but is currently just > > > > "reserved" which means it wants to prevent the allocator from using it. > > > > > > > > > > That may indeed be true of reserve_mem. > > > > The reserve_mem behaves like any other early allocation, it has proper > > struct pages (PG_Reserved) and it is mapped in the direct map so > > phys_to_virt() will work on it. > > > > As for mapping it to userspace, vm_iomap_memory() seems the best API to > > use. It has all the alignment checks and will refuse to map ranges that are > > not properly aligned and it will use vma information to create the right > > mappings. > > > > When using vmap() to get the virtual addresses (via the kmalloc_array() of > struct pages), the vunmap() gives the memory back to the memory allocator: > > ~# free > total used free shared buff/cache > available > Mem: 8185928 296676 7840576 920 148280 > 7889252 > Swap: 7812092 0 7812092 > ~# rmdir /sys/kernel/tracing/instances/boot_mapped/ > ~# free > total used free shared buff/cache > available > Mem: 8206404 290868 7866772 920 148384 > 7915536 > Swap: 7812092 0 7812092 > > With no issues. > > But if I use vmap_page_range(), how do I give that back to the memory > allocator?
But you don't need neither vmap() nor vmap_page_range() to have kernel page tables for memory that you get from reserve_mem. It's already mapped and plain phys_to_virt() gives you the virtual address you can use. > Calling vunmap() on that memory gives me: > > 1779.832484] ------------[ cut here ]------------ > [ 1779.834076] Trying to vunmap() nonexistent vm area (000000027c000000) > [ 1779.835941] WARNING: CPU: 6 PID: 956 at mm/vmalloc.c:3413 vunmap+0x5a/0x60 > > What's the proper way to say: "I no longer need this physical memory I > reserved, the kernel can now use it"? free_reserved_area() > -- Steve -- Sincerely yours, Mike.
