From: "Danilo Krummrich" <dakr@kernel.org>
To: "Shivam Kalra via B4 Relay" <devnull+shivamklr.cock.li@kernel.org>
Cc: shivamklr@cock.li, "Lorenzo Stoakes" <lorenzo.stoakes@oracle.com>,
"Vlastimil Babka" <vbabka@suse.cz>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
"Uladzislau Rezki" <urezki@gmail.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"Christian Brauner" <brauner@kernel.org>,
"Carlos Llamas" <cmllamas@google.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/4] rust: kvec: implement shrink_to and shrink_to_fit for Vec
Date: Sat, 07 Feb 2026 18:23:05 +0100 [thread overview]
Message-ID: <DG8WJPYVA0H1.1PO95BAW0TK3Y@kernel.org> (raw)
In-Reply-To: <20260207-binder-shrink-vec-v3-v3-2-8ff388563427@cock.li>
On Sat Feb 7, 2026 at 12:32 PM CET, Shivam Kalra via B4 Relay wrote:
> +impl<T, A: Shrinkable> Vec<T, A> {
I don't think we should have a Shrinkable trait with is_shrinkable(). This is a
decision taken by the backing Allocator's realloc() function already.
Instead, shrink_to() should be a normal method of Vec<A, T> and just call
A::realloc().
For the temporary workaround we can have a temporary ShrinkQuirk trait that has
methods that take the same arguments as shrink_to().
In Vec::shrink_to() we can then hook in before calling A::realloc() and apply
the quirk.
fn shrink_to() {
if self.shrink_needs_quirk() {
return self.shrink_quirk();
}
// Allocator backend decides.
A::realloc();
}
> + pub fn shrink_to(&mut self, min_capacity: usize, flags: Flags) -> Result<(), AllocError> {
> + let target_cap = core::cmp::max(self.len(), min_capacity);
> +
> + if self.capacity() <= target_cap {
> + return Ok(());
> + }
> +
> + if Self::is_zst() {
> + return Ok(());
> + }
> +
> + // SAFETY: `self.ptr` is valid by the type invariant.
> + if !unsafe { A::is_shrinkable(self.ptr.cast()) } {
> + return Ok(());
> + }
> +
> + // Only shrink if we would free at least one page.
> + let current_size = self.capacity() * core::mem::size_of::<T>();
> + let target_size = target_cap * core::mem::size_of::<T>();
> + let current_pages = current_size.div_ceil(PAGE_SIZE);
> + let target_pages = target_size.div_ceil(PAGE_SIZE);
This is the specific heuristic we use for the Vmalloc shrink workaround
(including when for KVmalloc is_vmalloc_addr() is true) and it doesn't belong
into the common code path.
But this goes away anyways with the above changes.
> + if current_pages <= target_pages {
> + return Ok(());
> + }
> +
> + if target_cap == 0 {
> + if !self.layout.is_empty() {
> + // SAFETY: `self.ptr` was allocated with `A`, layout matches.
> + unsafe { A::free(self.ptr.cast(), self.layout.into()) };
> + }
> + self.ptr = NonNull::dangling();
> + self.layout = ArrayLayout::empty();
> + return Ok(());
> + }
> +
> + // SAFETY: `target_cap <= self.capacity()` and original capacity was valid.
> + let new_layout = unsafe { ArrayLayout::<T>::new_unchecked(target_cap) };
> +
> + // TODO: Once vrealloc supports in-place shrinking (mm/vmalloc.c:4316), this
> + // explicit alloc+copy+free can potentially be replaced with realloc.
> + let new_ptr = A::alloc(new_layout.into(), flags, NumaNode::NO_NODE)?;
> +
> + // SAFETY: Both pointers are valid, non-overlapping, and properly aligned.
> + unsafe {
> + ptr::copy_nonoverlapping(self.as_ptr(), new_ptr.as_ptr().cast::<T>(), self.len);
> + }
> +
> + // SAFETY: `self.ptr` was allocated with `A`, layout matches.
> + unsafe { A::free(self.ptr.cast(), self.layout.into()) };
> +
> + // SAFETY: `new_ptr` is non-null because `A::alloc` succeeded.
> + self.ptr = unsafe { NonNull::new_unchecked(new_ptr.as_ptr().cast::<T>()) };
> + self.layout = new_layout;
> +
> + Ok(())
> + }
> +
> + /// Shrinks the capacity of the vector as much as possible.
> + ///
> + /// This is equivalent to calling `shrink_to(0, flags)`. See [`Vec::shrink_to`] for details.
> + ///
> + /// # Examples
> + ///
> + /// ```
> + /// use kernel::alloc::allocator::Vmalloc;
> + ///
> + /// let elements_per_page = kernel::page::PAGE_SIZE / core::mem::size_of::<u32>();
> + /// let mut v: Vec<u32, Vmalloc> = Vec::with_capacity(elements_per_page * 4, GFP_KERNEL)?;
You can just use VVec<u32>.
> + /// v.push(1, GFP_KERNEL)?;
> + /// v.push(2, GFP_KERNEL)?;
> + /// v.push(3, GFP_KERNEL)?;
> + ///
> + /// v.shrink_to_fit(GFP_KERNEL)?;
> + /// # Ok::<(), Error>(())
> + /// ```
> + pub fn shrink_to_fit(&mut self, flags: Flags) -> Result<(), AllocError> {
> + self.shrink_to(0, flags)
> + }
> +}
> +
> impl<T: Clone, A: Allocator> Vec<T, A> {
> /// Extend the vector by `n` clones of `value`.
> pub fn extend_with(&mut self, n: usize, value: T, flags: Flags) -> Result<(), AllocError> {
>
> --
> 2.43.0
next prev parent reply other threads:[~2026-02-07 17:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-07 11:32 [PATCH v3 0/4] rust: alloc: add Vec shrinking methods Shivam Kalra via B4 Relay
2026-02-07 11:32 ` [PATCH v3 1/4] rust: alloc: introduce Shrinkable trait Shivam Kalra via B4 Relay
2026-02-07 11:32 ` [PATCH v3 2/4] rust: kvec: implement shrink_to and shrink_to_fit for Vec Shivam Kalra via B4 Relay
2026-02-07 17:23 ` Danilo Krummrich [this message]
2026-02-08 16:11 ` Shivam Kalra
2026-02-07 11:32 ` [PATCH v3 3/4] rust: alloc: add KUnit tests for Vec shrink operations Shivam Kalra via B4 Relay
2026-02-07 11:32 ` [PATCH v3 4/4] rust: binder: shrink all_procs when deregistering processes Shivam Kalra via B4 Relay
2026-02-09 13:54 ` Alice Ryhl
2026-02-10 11:47 ` Shivam Kalra
2026-02-10 13:38 ` [PATCH v3 0/4] rust: alloc: add Vec shrinking methods Shivam Kalra
2026-02-10 13:57 ` Alice Ryhl
2026-02-10 15:05 ` Danilo Krummrich
2026-02-10 17:42 ` Shivam Kalra
2026-02-10 20:05 ` Alice Ryhl
2026-02-10 20:43 ` Danilo Krummrich
2026-02-10 20:53 ` Danilo Krummrich
2026-02-10 20:56 ` Danilo Krummrich
2026-02-10 20:58 ` Alice Ryhl
2026-02-10 21:11 ` Danilo Krummrich
2026-02-11 1:08 ` Shivam Kalra
2026-02-11 6:51 ` Alice Ryhl
2026-02-11 8:41 ` Shivam Kalra
2026-02-11 8:57 ` Danilo Krummrich
2026-02-11 9:35 ` 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=DG8WJPYVA0H1.1PO95BAW0TK3Y@kernel.org \
--to=dakr@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=arve@android.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=brauner@kernel.org \
--cc=cmllamas@google.com \
--cc=devnull+shivamklr.cock.li@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=shivamklr@cock.li \
--cc=tkjos@android.com \
--cc=tmgross@umich.edu \
--cc=urezki@gmail.com \
--cc=vbabka@suse.cz \
/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