[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z0Ylr1cJ2AZ6rcXO@casper.infradead.org>
Date: Tue, 26 Nov 2024 19:46:55 +0000
From: Matthew Wilcox <willy@...radead.org>
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,
"Liam R. Howlett" <Liam.Howlett@...cle.com>
Subject: Re: [PATCH v5 4/9] binder: remove struct binder_lru_page
On Tue, Nov 26, 2024 at 06:40:07PM +0000, Carlos Llamas wrote:
> Remove the redundant struct binder_lru_page concept. Instead, let's use
> available struct page->lru and page->private members directly to achieve
> the same functionality. This reduces the maximum memory allocated for
> alloc->pages from 32768 down to 8192 bytes (aarch64). Savings are per
> binder instance.
>
> Note that Matthew pointed out that some of the page members used in this
> patch (e.g. page->lru) are likely going to be removed in the near future
> [1]. Binder will adopt an alternative solution when this happens.
It's not just "near future". page->index is going away if not next
merge window, then the merge window after. page->mapping is going to
follow it, and page->lru after that. Please find another way now.
Powered by blists - more mailing lists