From: Uladzislau Rezki <urezki@gmail.com>
To: Fujunjie <fujunjie1@qq.com>, shivamkalra98@zohomail.in
Cc: Uladzislau Rezki <urezki@gmail.com>,
akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, shivamkalra98@zohomail.in
Subject: Re: [RFC PATCH 0/1] mm/vmalloc: reclaim tail resources on large vrealloc() shrink
Date: Mon, 27 Apr 2026 19:07:28 +0200 [thread overview]
Message-ID: <ae-X0MTt6GtCssA2@milan> (raw)
In-Reply-To: <tencent_54339C62C9BCA8C7ED48DB0D91451157FB06@qq.com>
On Tue, Apr 28, 2026 at 12:38:59AM +0800, Fujunjie wrote:
>
>
> On Tue, Apr 28, 2026 at 00:29, Uladzislau Rezki wrote:
> > On Sun, Apr 26, 2026 at 05:28:56AM +0000, fujunjie wrote:
> >> Hi,
> >>
> >> This RFC explores closing the resource retention gap in the vmalloc-backed
> >> shrink path of vrealloc().
> >>
> >> Today, when a vmalloc-backed allocation is shrunk, vrealloc() updates the
> >> requested size but can keep most of the old vmalloc mapping and backing pages
> >> alive. For sufficiently large shrink operations, this can retain a large amount
> >> of tail resources even though the logical object became much smaller.
> >>
> >> This first RFC keeps the scope intentionally conservative:
> >>
> >> - only ordinary VM_ALLOC areas
> >> - only page_order == 0 allocations
> >> - skip more complex vmalloc object types
> >> - only reclaim tail resources when the retained waste is at least PMD_SIZE
> >>
> >> The current evidence supports this as a resource reclamation fix rather than a
> >> workload-tuned performance optimization. Local validation currently covers:
> >>
> >> - synthetic large shrink correctness
> >> - shrink-then-grow regression
> >> - threshold boundary correctness for the current heuristic
> >> - KASAN run-rootfs vmalloc_oob regression coverage
> >>
> >> I would especially appreciate feedback on:
> >>
> >> 1. whether this shrink direction is desirable upstream at all
> >> 2. whether the initial object-type restrictions are reasonable
> >> 3. whether a conservative PMD_SIZE threshold is an acceptable first heuristic
> >> 4. what kind of in-tree regression test would be preferred
> >>
> > Could you please have a look at this work:
> > https://lore.kernel.org/all/20260420-vmalloc-shrink-v11-0-cad80b00853a@zohomail.in/
> >
> > Shivam is working on the same feature. Could you please check?
> >
> > --
> > Uladzislau Rezki
>
> Thanks for the pointer, and sorry for missing Shivam's series before sending this RFC.
>
> I will read through it first and avoid duplicating the effort.
>
Thank you!
Maybe Shivam can also have a look at your work. I put him into To.
--
Uladzislau Rezki
prev parent reply other threads:[~2026-04-27 17:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-26 5:28 [RFC PATCH 0/1] mm/vmalloc: reclaim tail resources on large vrealloc() shrink fujunjie
2026-04-27 16:29 ` Uladzislau Rezki
2026-04-27 16:38 ` Fujunjie
2026-04-27 17:07 ` Uladzislau Rezki [this message]
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=ae-X0MTt6GtCssA2@milan \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=fujunjie1@qq.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shivamkalra98@zohomail.in \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox