[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH5fLghRmYFLa-ag9vo4vv_P281jXGFfsDFyGq5pk5g0PUXtUA@mail.gmail.com>
Date: Thu, 18 Apr 2024 10:21:49 +0200
From: Alice Ryhl <aliceryhl@...gle.com>
To: Carlos Llamas <cmllamas@...gle.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Arve Hjønnevåg <arve@...roid.com>,
Todd Kjos <tkjos@...roid.com>, Martijn Coenen <maco@...roid.com>,
Joel Fernandes <joel@...lfernandes.org>, Christian Brauner <brauner@...nel.org>,
Suren Baghdasaryan <surenb@...gle.com>, linux-kernel@...r.kernel.org, kernel-team@...roid.com,
Tim Murray <timmurray@...gle.com>
Subject: Re: [PATCH 3/4] binder: add support for PF_LARGE_HANDLES
On Wed, Apr 17, 2024 at 9:15 PM Carlos Llamas <cmllamas@...gle.com> wrote:
>
> Introduce the PF_LARGE_HANDLES flag to enable the use of monotonically
> increasing counters to generate handles. This improves performance in
> transactions when dealing with a large number of references.
>
> The legacy logic performs an inorder traversal of an rbtree to find the
> smallest unused handle. This limitation is due to userspace using the
> handles as indexes (e.g. in vectors). The new logic scales much better
> but requires userspace to support large handle numbers.
>
> The benchmark below with 100,000 references shows the performance gains
> in binder_get_ref_for_node_olocked() calls with PF_LARGE_HANDLES.
>
> [ 167.855945] binder_get_ref_for_node_olocked: 17us (flag on)
> [ 237.088072] binder_get_ref_for_node_olocked: 18178us (flag off)
>
> Suggested-by: Tim Murray <timmurray@...gle.com>
> Suggested-by: Alice Ryhl <aliceryhl@...gle.com>
> Signed-off-by: Carlos Llamas <cmllamas@...gle.com>
Reviewed-by: Alice Ryhl <aliceryhl@...gle.com>
Powered by blists - more mailing lists