[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YPcFVScLa2GGY2RP@casper.infradead.org>
Date: Tue, 20 Jul 2021 18:18:13 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Mike Rapoport <rppt@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v14 000/138] Memory folios
On Tue, Jul 20, 2021 at 06:35:50PM +0300, Mike Rapoport wrote:
> On Tue, Jul 20, 2021 at 04:23:29PM +0100, Matthew Wilcox wrote:
> > Which patch did you go up to for that? If you're going past patch 50 or
> > so, then you're starting to add functionality (ie support for arbitrary
> > order pages), so a certain amount of extra code size might be expected.
> > I measured 6KB at patch 32 or so, then between patch 32 & 50 was pretty
> > much a wash.
>
> I've used folio_14 tag:
>
> commit 480552d0322d855d146c0fa6fdf1e89ca8569037 (HEAD, tag: folio_14)
> Author: Matthew Wilcox (Oracle) <willy@...radead.org>
> Date: Wed Feb 5 11:27:01 2020 -0500
>
> mm/readahead: Add multi-page folio readahead
Probably worth trying the for-next tag instead to get a meaningful
comparison of how much using folios saves over pages.
I don't want to give the impression that this is all that can be
saved by switching to folios. There are still hundreds of places that
call PageFoo(), SetPageFoo(), ClearPageFoo(), put_page(), get_page(),
lock_page() and so on. There's probably another 20KB of code that can
be removed that way.
Powered by blists - more mailing lists