[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <165119746546.1648.12856939779038565632@noble.neil.brown.name>
Date: Fri, 29 Apr 2022 11:57:45 +1000
From: "NeilBrown" <neilb@...e.de>
To: "Andrew Morton" <akpm@...ux-foundation.org>
Cc: "Geert Uytterhoeven" <geert+renesas@...der.be>,
"Christoph Hellwig" <hch@....de>,
"Miaohe Lin" <linmiaohe@...wei.com>, linux-nfs@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] MM: handle THP in swap_*page_fs()
On Fri, 29 Apr 2022, Andrew Morton wrote:
> On Fri, 29 Apr 2022 10:43:34 +1000 NeilBrown <neilb@...e.de> wrote:
>
> > Pages passed to swap_readpage()/swap_writepage() are not necessarily all
> > the same size - there may be transparent-huge-pages involves.
> >
> > The BIO paths of swap_*page() handle this correctly, but the SWP_FS_OPS
> > path does not.
> >
> > So we need to use thp_size() to find the size, not just assume
> > PAGE_SIZE, and we need to track the total length of the request, not
> > just assume it is "page * PAGE_SIZE".
>
> Cool. I added this in the series after
> mm-submit-multipage-write-for-swp_fs_ops-swap-space.patch. I could
> later squash it into that patch if you think that's more logical.
I think it best to keep it separate, though that position is good.
If we were to squash, some would need to go into the "submit multipage
reads" patch, and some in "submit multipage writes". IF you wanted to
do that I wouldn't object but I don't think it is needed.
Thanks,
NeilBrown
Powered by blists - more mailing lists