From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6EDC73783CC for ; Mon, 9 Feb 2026 13:54:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770645256; cv=none; b=RWSZ29/SnWUJJgSTtmtJZIUKIbIGce5/iB4YLtAwLLICe5Uw62I+e9B40rAOqybPpPx362y7q0y5PxpcqeFcWv0+nFkMeIBZuYbQ5cJ2g/v/0rH4ZSLkt2YzM1xqRYZ1ZGruxpeyLrcJkQtqqQrGZEjqYX/G6pFKetqZAPCwe/g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770645256; c=relaxed/simple; bh=Auxpjx5FMc2hhVQlgNfI5ygzOw21gO5dmGldCK9mvCY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=IIUuEAutN7KLaRx3jw//eKo/XyT/RmBT4lpzpSURhcQAZ+Vxk+tMGBHNQEexxpaFCfnanurQ0xG1nsMt2SmBk43ObRfujK6qZWdNO3u/UjfsyZ5ZBPJz9ODFRJ0GMxxbjecFqHCyWO0ibPqlDwjqOTJ4pmBpBemEog38lxB//HQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=SFwBlE5S; arc=none smtp.client-ip=209.85.221.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="SFwBlE5S" Received: by mail-wr1-f74.google.com with SMTP id ffacd0b85a97d-43630b02fb4so2310388f8f.3 for ; Mon, 09 Feb 2026 05:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770645255; x=1771250055; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=xCBcj3Yd7ziwWPdB67tTlI6vTXFxVIocC5zGKA0hdqg=; b=SFwBlE5SLng5TjV5AmM/EniIiOxGzTMJNY6DX0TZ7BotupyrnmC6zXcGQMl6CCrQYV IJHCeDnAw5XMszLQpztwPFzLVtE9FcRGtkkdleUB6i7b2QevQ/8f6ARJIb90HdOA3qA0 /qQ2vxNoy/BsrddTTBKwhhRv+/yafpYli/SaNQhRkato7SOcM85R4vwbDRtX0sWB2TuQ R6+uxfDQW9K0yLzvnpvud3Kj1dixqN97yMDZBZ9eUDP9yFmrW6HWifp65UPY1FGa26TL sZ0VF/L6Dkwl3zubd5ovncEU1jsO5xqWVB7P4DKjBFsPyaAU89iysayY5haP3ipFWzpi KOkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770645255; x=1771250055; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xCBcj3Yd7ziwWPdB67tTlI6vTXFxVIocC5zGKA0hdqg=; b=qDsn8RNne8oQ/nC/GL5Ax+4+bk3v5GqZLXF0Aq9TPD8IbylrC/Hq31XOK3K4MQ0lsb PQfM8itHy1rNRsW3LMtbss9M3Gu3mOxEOkrv3Hq6tvfLEmC5IfWFZh6iISMIAIEy5Ksz G2XvZuBkyTmNTXiqhxyMY8XT7Cf4TluM0kqFvuZ4+mjObbSM7Xzyvbkbd9GxvJAs/J9m enHQzaFb4DhVvY2HwGavixiye9uPFYhECmSqBoqAEZD44pq4Ir1CHUeKN/KxSpxpr2me dkQbbub4+NWs4WNC4q8ALEgysoKTB+yh4E/hz3W24TYPYVh5SeugzAUp4NYHESrwiofp 5pEw== X-Forwarded-Encrypted: i=1; AJvYcCWbIZKaskFobz/ZsPofqI0Oi2IyaKmN3If0Qc/gInVy+Qp5dL8HRN/P/rn3VbF+cwzjdcsRMO2Kt/1fSMI=@vger.kernel.org X-Gm-Message-State: AOJu0YwuBNQeNX27qLY3jTfofrNBXecfrCl5ME8YEmCUMzmrglu42Jp4 /rLCZd2+dXALcdB88xP5xFD4kgY/2XnfOxHAcA6ExzY/UIO7TIAihCEESuCporUgUsppUMBz9Jl 7BxVTDQLEPD16RhKfBg== X-Received: from wre13.prod.google.com ([2002:a05:6000:4b0d:b0:437:73a2:2d43]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:2285:b0:427:526:16aa with SMTP id ffacd0b85a97d-436293b6ae1mr16429455f8f.58.1770645254841; Mon, 09 Feb 2026 05:54:14 -0800 (PST) Date: Mon, 9 Feb 2026 13:54:13 +0000 In-Reply-To: <20260207-binder-shrink-vec-v3-v3-4-8ff388563427@cock.li> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260207-binder-shrink-vec-v3-v3-0-8ff388563427@cock.li> <20260207-binder-shrink-vec-v3-v3-4-8ff388563427@cock.li> Message-ID: Subject: Re: [PATCH v3 4/4] rust: binder: shrink all_procs when deregistering processes From: Alice Ryhl To: shivamklr@cock.li Cc: Danilo Krummrich , Lorenzo Stoakes , Vlastimil Babka , "Liam R. Howlett" , Uladzislau Rezki , Miguel Ojeda , Boqun Feng , Gary Guo , "=?utf-8?B?QmrDtnJu?= Roy Baron" , Benno Lossin , Andreas Hindborg , Trevor Gross , Greg Kroah-Hartman , "Arve =?utf-8?B?SGrDuG5uZXbDpWc=?=" , Todd Kjos , Christian Brauner , Carlos Llamas , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" 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 > > 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 > --- > 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, proc: &Arc) { > } > 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