diff mbox series

[v2,23/28] binder: document the final page calculation

Message ID 20231201172212.1813387-24-cmllamas@google.com
State New
Headers
Series binder: convert alloc->mutex to spinlock |

Commit Message

Carlos Llamas Dec. 1, 2023, 5:21 p.m. UTC 
  The code to determine the page range for binder_lru_freelist_del() is
quite obscure. It leverages the buffer_size calculated before doing an
oversized buffer split. This is used to figure out if the last page is
being shared with another active buffer. If so, the page gets trimmed
out of the range as it has been previously removed from the freelist.

This would be equivalent to getting the start page of the next in-use
buffer explicitly. However, the code for this is much larger as we can
see in binder_free_buf_locked() routine. Instead, lets settle on
documenting the tricky step and using better names for now.

I believe an ideal solution would be to count the binder_page->users to
determine when a page should be added or removed from the freelist.
However, this is a much bigger change than what I'm willing to risk at
this time.

Signed-off-by: Carlos Llamas <cmllamas@google.com>
---
 drivers/android/binder_alloc.c | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

Comments

Alice Ryhl Dec. 4, 2023, 11:57 a.m. UTC | #1 
> The code to determine the page range for binder_lru_freelist_del() is
> quite obscure. It leverages the buffer_size calculated before doing an
> oversized buffer split. This is used to figure out if the last page is
> being shared with another active buffer. If so, the page gets trimmed
> out of the range as it has been previously removed from the freelist.
> 
> This would be equivalent to getting the start page of the next in-use
> buffer explicitly. However, the code for this is much larger as we can
> see in binder_free_buf_locked() routine. Instead, lets settle on
> documenting the tricky step and using better names for now.
> 
> I believe an ideal solution would be to count the binder_page->users to
> determine when a page should be added or removed from the freelist.
> However, this is a much bigger change than what I'm willing to risk at
> this time.
> 
> Signed-off-by: Carlos Llamas <cmllamas@google.com>

Yes, this does help somewhat.

However, `curr_last_page` is actually not the last page. It's the last
page plus one, since `binder_lru_freelist_del` is exclusive on this
argument. Maybe rename it to `curr_after_last_page` or something like
that? Or maybe even just `curr_last_page_plus_one`.

Alice
Carlos Llamas Dec. 4, 2023, 2:39 p.m. UTC | #2 
On Mon, Dec 04, 2023 at 11:57:27AM +0000, Alice Ryhl wrote:
> > The code to determine the page range for binder_lru_freelist_del() is
> > quite obscure. It leverages the buffer_size calculated before doing an
> > oversized buffer split. This is used to figure out if the last page is
> > being shared with another active buffer. If so, the page gets trimmed
> > out of the range as it has been previously removed from the freelist.
> > 
> > This would be equivalent to getting the start page of the next in-use
> > buffer explicitly. However, the code for this is much larger as we can
> > see in binder_free_buf_locked() routine. Instead, lets settle on
> > documenting the tricky step and using better names for now.
> > 
> > I believe an ideal solution would be to count the binder_page->users to
> > determine when a page should be added or removed from the freelist.
> > However, this is a much bigger change than what I'm willing to risk at
> > this time.
> > 
> > Signed-off-by: Carlos Llamas <cmllamas@google.com>
> 
> Yes, this does help somewhat.
> 
> However, `curr_last_page` is actually not the last page. It's the last
> page plus one, since `binder_lru_freelist_del` is exclusive on this
> argument. Maybe rename it to `curr_after_last_page` or something like
> that? Or maybe even just `curr_last_page_plus_one`.

hmmm, I don't know. I think this could be more confusing, the plus-one
is only because of the way that binder_lru_freelist_del() processes the
final page. So you could interpret the name both ways. Do we _really_
need the extra comments to make it clear?

This solution is too complex anyway, it should really be replaced with a
binder_page->nr_users to determine when to add/remove from the lru.

--
Carlos Llamas
Alice Ryhl Dec. 4, 2023, 2:43 p.m. UTC | #3 
On Mon, Dec 4, 2023 at 3:39 PM Carlos Llamas <cmllamas@google.com> wrote:
>
> On Mon, Dec 04, 2023 at 11:57:27AM +0000, Alice Ryhl wrote:
> > > The code to determine the page range for binder_lru_freelist_del() is
> > > quite obscure. It leverages the buffer_size calculated before doing an
> > > oversized buffer split. This is used to figure out if the last page is
> > > being shared with another active buffer. If so, the page gets trimmed
> > > out of the range as it has been previously removed from the freelist.
> > >
> > > This would be equivalent to getting the start page of the next in-use
> > > buffer explicitly. However, the code for this is much larger as we can
> > > see in binder_free_buf_locked() routine. Instead, lets settle on
> > > documenting the tricky step and using better names for now.
> > >
> > > I believe an ideal solution would be to count the binder_page->users to
> > > determine when a page should be added or removed from the freelist.
> > > However, this is a much bigger change than what I'm willing to risk at
> > > this time.
> > >
> > > Signed-off-by: Carlos Llamas <cmllamas@google.com>
> >
> > Yes, this does help somewhat.
> >
> > However, `curr_last_page` is actually not the last page. It's the last
> > page plus one, since `binder_lru_freelist_del` is exclusive on this
> > argument. Maybe rename it to `curr_after_last_page` or something like
> > that? Or maybe even just `curr_last_page_plus_one`.
>
> hmmm, I don't know. I think this could be more confusing, the plus-one
> is only because of the way that binder_lru_freelist_del() processes the
> final page. So you could interpret the name both ways. Do we _really_
> need the extra comments to make it clear?
>
> This solution is too complex anyway, it should really be replaced with a
> binder_page->nr_users to determine when to add/remove from the lru.

You could also just remove the `next_used_page` part entirely. This
means that you will sometimes call `binder_lru_freelist_del` on a page
that's in use, but that's just a no-op.

Alice
Carlos Llamas Dec. 4, 2023, 2:53 p.m. UTC | #4 
On Mon, Dec 04, 2023 at 03:43:54PM +0100, Alice Ryhl wrote:
> You could also just remove the `next_used_page` part entirely. This
> means that you will sometimes call `binder_lru_freelist_del` on a page
> that's in use, but that's just a no-op.

Yes, that is right and I did look into this. The WARN_ON(!on_lru) checks
are a bit confusing when it's a no-op as you mention. The purpose though
is to assert the "algorithm" of add/del pages from the lru is somewhat
correct (particularly the page range).

--
Carlos Llamas
diff mbox series

Patch

diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c
index 052a8c3b0ce1..edd9714ec9f5 100644
--- a/drivers/android/binder_alloc.c
+++ b/drivers/android/binder_alloc.c
@@ -446,8 +446,8 @@  static struct binder_buffer *binder_alloc_new_buf_locked(
 	struct rb_node *n = alloc->free_buffers.rb_node;
 	struct rb_node *best_fit = NULL;
 	struct binder_buffer *buffer;
-	unsigned long has_page_addr;
-	unsigned long end_page_addr;
+	unsigned long next_used_page;
+	unsigned long curr_last_page;
 	size_t buffer_size;
 
 	if (is_async && alloc->free_async_space < size) {
@@ -500,12 +500,16 @@  static struct binder_buffer *binder_alloc_new_buf_locked(
 		     "%d: binder_alloc_buf size %zd got buffer %pK size %zd\n",
 		      alloc->pid, size, buffer, buffer_size);
 
-	has_page_addr = (buffer->user_data + buffer_size) & PAGE_MASK;
-	end_page_addr = PAGE_ALIGN(buffer->user_data + size);
-	if (end_page_addr > has_page_addr)
-		end_page_addr = has_page_addr;
+	/*
+	 * Now we remove the pages from the freelist. A clever calculation
+	 * with buffer_size determines if the last page is shared with an
+	 * adjacent in-use buffer. In such case, the page has been already
+	 * removed from the freelist so we trim our range short.
+	 */
+	next_used_page = (buffer->user_data + buffer_size) & PAGE_MASK;
+	curr_last_page = PAGE_ALIGN(buffer->user_data + size);
 	binder_lru_freelist_del(alloc, PAGE_ALIGN(buffer->user_data),
-				end_page_addr);
+				min(next_used_page, curr_last_page));
 
 	rb_erase(&buffer->rb_node, &alloc->free_buffers);
 	buffer->free = 0;