[PATCH v3 4/4] rust: binder: shrink all_procs when deregistering processes

Shivam Kalra via B4 Relay posted 4 patches 3 days, 3 hours ago
[PATCH v3 4/4] rust: binder: shrink all_procs when deregistering processes
Posted by Shivam Kalra via B4 Relay 3 days, 3 hours ago
From: Shivam Kalra <shivamklr@cock.li>

When a process is deregistered from the binder context, the all_procs
vector may have significant unused capacity. Add logic to shrink the
vector when capacity exceeds 128 and usage drops below 50%, reducing
memory overhead for long-running systems.

The shrink operation uses GFP_KERNEL and is allowed to fail gracefully
since it is purely an optimization. The vector remains valid and
functional even if shrinking fails.

Signed-off-by: Shivam Kalra <shivamklr@cock.li>
---
 drivers/android/binder/context.rs | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/android/binder/context.rs b/drivers/android/binder/context.rs
index 9cf437c025a20..f2505fbf17403 100644
--- a/drivers/android/binder/context.rs
+++ b/drivers/android/binder/context.rs
@@ -94,6 +94,16 @@ pub(crate) fn deregister_process(self: &Arc<Self>, proc: &Arc<Process>) {
         }
         let mut manager = self.manager.lock();
         manager.all_procs.retain(|p| !Arc::ptr_eq(p, proc));
+
+        // Shrink the vector if it has significant unused capacity.
+        // Only shrink if capacity > 128 to avoid repeated reallocations for small vectors.
+        let len = manager.all_procs.len();
+        let cap = manager.all_procs.capacity();
+        if cap > 128 && len < cap / 2 {
+            // Shrink to current length. Ignore allocation failures since this is just an
+            // optimization; the vector remains valid even if shrinking fails.
+            let _ = manager.all_procs.shrink_to(len, GFP_KERNEL);
+        }
     }
 
     pub(crate) fn set_manager_node(&self, node_ref: NodeRef) -> Result {

-- 
2.43.0
Re: [PATCH v3 4/4] rust: binder: shrink all_procs when deregistering processes
Posted by Alice Ryhl 1 day, 1 hour ago
On Sat, Feb 07, 2026 at 05:02:50PM +0530, Shivam Kalra via B4 Relay wrote:
> [PATCH v3 4/4] rust: binder: shrink all_procs when deregistering

The usual prefix for Rust Binder changes is rust_binder:, not
rust: binder:.

> From: Shivam Kalra <shivamklr@cock.li>
> 
> When a process is deregistered from the binder context, the all_procs
> vector may have significant unused capacity. Add logic to shrink the
> vector when capacity exceeds 128 and usage drops below 50%, reducing
> memory overhead for long-running systems.
> 
> The shrink operation uses GFP_KERNEL and is allowed to fail gracefully
> since it is purely an optimization. The vector remains valid and
> functional even if shrinking fails.
> 
> Signed-off-by: Shivam Kalra <shivamklr@cock.li>
> ---
>  drivers/android/binder/context.rs | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/android/binder/context.rs b/drivers/android/binder/context.rs
> index 9cf437c025a20..f2505fbf17403 100644
> --- a/drivers/android/binder/context.rs
> +++ b/drivers/android/binder/context.rs
> @@ -94,6 +94,16 @@ pub(crate) fn deregister_process(self: &Arc<Self>, proc: &Arc<Process>) {
>          }
>          let mut manager = self.manager.lock();
>          manager.all_procs.retain(|p| !Arc::ptr_eq(p, proc));
> +
> +        // Shrink the vector if it has significant unused capacity.
> +        // Only shrink if capacity > 128 to avoid repeated reallocations for small vectors.
> +        let len = manager.all_procs.len();
> +        let cap = manager.all_procs.capacity();
> +        if cap > 128 && len < cap / 2 {
> +            // Shrink to current length. Ignore allocation failures since this is just an
> +            // optimization; the vector remains valid even if shrinking fails.
> +            let _ = manager.all_procs.shrink_to(len, GFP_KERNEL);

Hmm. This way we need to reallocate immediately if one more process is
added. How about:

if len < cap / 4 {
    shrink_to(cap / 2);
}

Alice
Re: [PATCH v3 4/4] rust: binder: shrink all_procs when deregistering processes
Posted by Shivam Kalra 3 hours ago
On 09/02/26 19:24, Alice Ryhl wrote:
> 
> Hmm. This way we need to reallocate immediately if one more process is
> added. How about:
> 
> if len < cap / 4 {
>     shrink_to(cap / 2);
> }
> 
> Alice
Good point, that avoids the shrink-then-immediately-regrow pattern.
Will adopt this for v4.