From: Alice Ryhl <aliceryhl@google.com>
To: shivamkalra98@zohomail.in
Cc: Andrew Morton <akpm@linux-foundation.org>,
Uladzislau Rezki <urezki@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Danilo Krummrich <dakr@kernel.org>
Subject: Re: [PATCH v3 2/2] mm/vmalloc: free unused pages on vrealloc() shrink
Date: Thu, 12 Mar 2026 07:59:49 +0000 [thread overview]
Message-ID: <abJydalLnoddywQq@google.com> (raw)
In-Reply-To: <20260309-vmalloc-shrink-v3-2-5590fd8de2eb@zohomail.in>
On Mon, Mar 09, 2026 at 05:25:46PM +0530, Shivam Kalra via B4 Relay wrote:
> From: Shivam Kalra <shivamkalra98@zohomail.in>
>
> When vrealloc() shrinks an allocation and the new size crosses a page
> boundary, unmap and free the tail pages that are no longer needed. This
> reclaims physical memory that was previously wasted for the lifetime
> of the allocation.
>
> The heuristic is simple: always free when at least one full page becomes
> unused. Huge page allocations (page_order > 0) are skipped, as partial
> freeing would require splitting.
>
> The virtual address reservation (vm->size / vmap_area) is intentionally
> kept unchanged, preserving the address for potential future grow-in-place
> support.
>
> Fix the grow-in-place check to compare against vm->nr_pages rather than
> get_vm_area_size(), since the latter reflects the virtual reservation
> which does not shrink. Without this fix, a grow after shrink would
> access freed pages.
>
> Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
> ---
> mm/vmalloc.c | 19 ++++++++++++++-----
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 42ae68450a90..114e0bd1030e 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -4344,14 +4344,23 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
> goto need_realloc;
> }
>
> - /*
> - * TODO: Shrink the vm_area, i.e. unmap and free unused pages. What
> - * would be a good heuristic for when to shrink the vm_area?
> - */
> if (size <= old_size) {
> + unsigned int new_nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
> +
> /* Zero out "freed" memory, potentially for future realloc. */
> if (want_init_on_free() || want_init_on_alloc(flags))
> memset((void *)p + size, 0, old_size - size);
> +
> + /* Free tail pages when shrink crosses a page boundary. */
> + if (new_nr_pages < vm->nr_pages && !vm_area_page_order(vm)) {
> + unsigned long addr = (unsigned long)p;
> +
> + vunmap_range(addr + (new_nr_pages << PAGE_SHIFT),
> + addr + (vm->nr_pages << PAGE_SHIFT));
> +
> + vmalloc_free_pages(vm, new_nr_pages, vm->nr_pages);
This leaves the range vm->pages[new_nr_pages .. old_nr_pages] with
non-NULL but freed page pointers. It seems less error prone to set those
entries of vm->pages to NULL here.
Note that it's not a problem for existing usage of vmalloc_free_pages(),
because it is immediately followed by kvfree(vm->pages).
Alice
> + vm->nr_pages = new_nr_pages;
> + }
> vm->requested_size = size;
> kasan_vrealloc(p, old_size, size);
> return (void *)p;
> @@ -4360,7 +4369,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align
> /*
> * We already have the bytes available in the allocation; use them.
> */
> - if (size <= alloced_size) {
> + if (size <= (size_t)vm->nr_pages << PAGE_SHIFT) {
> /*
> * No need to zero memory here, as unused memory will have
> * already been zeroed at initial allocation time or during
>
> --
> 2.43.0
>
>
next prev parent reply other threads:[~2026-03-12 7:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 11:55 [PATCH v3 0/2] mm/vmalloc: free unused pages on vrealloc() shrink Shivam Kalra
2026-03-09 11:55 ` Shivam Kalra via B4 Relay
2026-03-09 11:55 ` [PATCH v3 1/2] mm/vmalloc: extract vmalloc_free_pages() helper from vfree() Shivam Kalra
2026-03-09 11:55 ` Shivam Kalra via B4 Relay
2026-03-11 17:34 ` Uladzislau Rezki
2026-03-14 7:00 ` Shivam Kalra
2026-03-09 11:55 ` [PATCH v3 2/2] mm/vmalloc: free unused pages on vrealloc() shrink Shivam Kalra
2026-03-09 11:55 ` Shivam Kalra via B4 Relay
2026-03-12 7:59 ` Alice Ryhl [this message]
2026-03-14 7:01 ` Shivam Kalra
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=abJydalLnoddywQq@google.com \
--to=aliceryhl@google.com \
--cc=akpm@linux-foundation.org \
--cc=dakr@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shivamkalra98@zohomail.in \
--cc=urezki@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.