[PATCH v2] rust_binder: speed up get_node_debug_info using lower_bound iter

[PATCH v2] rust_binder: speed up get_node_debug_info using lower_bound iter

[Rafael Passos]

Finding the next node in the RBTree can be done more efficiently using
the cursor_lower_bound, as it reduces cost from O(n) to O(log n).

Link: https://github.com/Rust-for-Linux/linux/issues/1249
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Rafael Passos <rafael@rcpassos.me>
---

V1: https://lore.kernel.org/rust-for-linux/20260728012249.3084154-1-rafael@rcpassos.me/
Changes from V1:
    - remove the "if/else" block checking if the current>prt.
      The cursor_lower_bound function returns the "key" or the next larger.
      This is indeed better, my check was unnecessary.
    - add a comment about this fact before the cursor_lower_bound


It took me a while to get the AOSP + Cuttlefish setup running, and
using the rust binder module. I got it working, and ran:
libhwbinder_benchmark libbinder_benchmark, hwbinderThroughputTest
            libhwbinder_latency and binderThroughputTest benches.
But apparently none of them used the function I touched (I added log).
Also, the "hw" variants like hwbinderThroughputTest kept logging a
 "worker_fx:217 condition:service->isRemote() failed" message.
I decided to send the v2 anyway.

I am thinking about writing a benchmark focused on node scaling
    (test N iterations with X nodes), and run with small and larger Xs.)
Would such a benchmark be welcome here in upstream mainline ?
It would be in either C or Rust (the AOSP ones are in C++).
Would it live under `tools/perf` ?

I looked at the kunit tests (`drivers/android/tests`) and they dont
cover the rust binder either. That's another thing I could try to add.


I'd love some feedback regarding next steps :)
Thanks,
Rafael Passos


 drivers/android/binder/process.rs | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/android/binder/process.rs b/drivers/android/binder/process.rs
index cdd1a90797266..68c9384fbf69f 100644
--- a/drivers/android/binder/process.rs
+++ b/drivers/android/binder/process.rs
@@ -1174,11 +1174,10 @@ fn get_node_debug_info(&self, data: UserSlice) -> Result {
 
         {
             let inner = self.inner.lock();
-            for (node_ptr, node) in &inner.nodes {
-                if *node_ptr > ptr {
-                    node.populate_debug_info(&mut out, &inner);
-                    break;
-                }
+            // cursor_lower_bound retrieves the "key" passed or the next existing larger key
+            if let Some(cursor) = inner.nodes.cursor_lower_bound(&(ptr+1)){
+                let (_, node) = cursor.current();
+                node.populate_debug_info(&mut out, &inner);
             }
         }
 
-- 
2.53.0

Re: [PATCH v2] rust_binder: speed up get_node_debug_info using lower_bound iter

[Alice Ryhl]

On Fri, Jul 31, 2026 at 10:31:03AM -0300, Rafael Passos wrote:
> Finding the next node in the RBTree can be done more efficiently using
> the cursor_lower_bound, as it reduces cost from O(n) to O(log n).
> 
> Link: https://github.com/Rust-for-Linux/linux/issues/1249
> Suggested-by: Alice Ryhl <aliceryhl@google.com>
> Signed-off-by: Rafael Passos <rafael@rcpassos.me>

This looks fine to me.

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

> It took me a while to get the AOSP + Cuttlefish setup running, and
> using the rust binder module. I got it working, and ran:
> libhwbinder_benchmark libbinder_benchmark, hwbinderThroughputTest
>             libhwbinder_latency and binderThroughputTest benches.
> But apparently none of them used the function I touched (I added log).
> Also, the "hw" variants like hwbinderThroughputTest kept logging a
>  "worker_fx:217 condition:service->isRemote() failed" message.
> I decided to send the v2 anyway.
> 
> I am thinking about writing a benchmark focused on node scaling
>     (test N iterations with X nodes), and run with small and larger Xs.)
> Would such a benchmark be welcome here in upstream mainline ?
> It would be in either C or Rust (the AOSP ones are in C++).
> Would it live under `tools/perf` ?
> 
> I looked at the kunit tests (`drivers/android/tests`) and they dont
> cover the rust binder either. That's another thing I could try to add.

In Android this is used by libmemunreachable when checking whether a
process has a memory leak. The perf matters because if the number of
nodes is very large, invoking the ioctl repeatedly many times could take
a seriously large amount of time. Seconds or even more.

Alice