[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z0ZN8QzIlK_NpOEg@google.com>
Date: Tue, 26 Nov 2024 22:38:41 +0000
From: Carlos Llamas <cmllamas@...gle.com>
To: Matthew Wilcox <willy@...radead.org>
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 07:46:55PM +0000, Matthew Wilcox wrote:
> 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.
I see. I've found your patches removing page->index now. I'll go ahead
and rewire this to hang everything under page->private. Thanks for the
heads up Matthew.
--
Carlos Llamas
Powered by blists - more mailing lists