All of lore.kernel.org
 help / color / mirror / Atom feed
From: "NeilBrown" <neilb@suse.de>
To: "Andrew Morton" <akpm@linux-foundation.org>
Cc: "Geert Uytterhoeven" <geert+renesas@glider.be>,
	"Christoph Hellwig" <hch@lst.de>,
	"Miaohe Lin" <linmiaohe@huawei.com>,
	linux-nfs@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] MM: handle THP in swap_*page_fs()
Date: Fri, 29 Apr 2022 11:57:45 +1000	[thread overview]
Message-ID: <165119746546.1648.12856939779038565632@noble.neil.brown.name> (raw)
In-Reply-To: <20220428182132.883a082ad8918fd5f8073130@linux-foundation.org>

On Fri, 29 Apr 2022, Andrew Morton wrote:
> On Fri, 29 Apr 2022 10:43:34 +1000 NeilBrown <neilb@suse.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

  reply	other threads:[~2022-04-29  1:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-29  0:43 [PATCH 0/2] Finalising swap-over-NFS patches NeilBrown
2022-04-29  0:43 ` [PATCH 1/2] MM: handle THP in swap_*page_fs() NeilBrown
2022-04-29  1:21   ` Andrew Morton
2022-04-29  1:57     ` NeilBrown [this message]
2022-04-29  8:13   ` Miaohe Lin
2022-04-29 19:04   ` Yang Shi
2022-05-02  4:23     ` NeilBrown
2022-05-02 17:48       ` Yang Shi
2022-05-04 23:41         ` NeilBrown
2022-05-06  2:56           ` ying.huang
2022-04-29  0:43 ` [PATCH 2/2] NFS: rename nfs_direct_IO and use as ->swap_rw NeilBrown
2022-04-29  1:23   ` Andrew Morton
2022-04-29  2:05     ` NeilBrown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=165119746546.1648.12856939779038565632@noble.neil.brown.name \
    --to=neilb@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=geert+renesas@glider.be \
    --cc=hch@lst.de \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.