From: Hugh Dickins <hughd@google.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Chandan Babu R <chandan.babu@oracle.com>,
"Darrick J. Wong" <djwong@kernel.org>,
Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <willy@infradead.org>,
linux-xfs@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 14/20] xfs: use shmem_get_folio in xfile_obj_store
Date: Thu, 15 Feb 2024 23:40:41 -0800 (PST) [thread overview]
Message-ID: <8eba6e1d-3e93-9586-17f3-86dcf25f5ae4@google.com> (raw)
In-Reply-To: <20240129143502.189370-15-hch@lst.de>
On Mon, 29 Jan 2024, Christoph Hellwig wrote:
> Switch to using shmem_get_folio and manually dirtying the page instead
> of abusing aops->write_begin and aops->write_end in xfile_get_page.
>
> This simplifies the code by not doing indirect calls of not actually
> exported interfaces that don't really fit the use case very well, and
> happens to get us large folio support for free.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reviewed-by: Darrick J. Wong <djwong@kernel.org>
> ---
> fs/xfs/scrub/xfile.c | 73 ++++++++++++++++----------------------------
> 1 file changed, 27 insertions(+), 46 deletions(-)
>
> diff --git a/fs/xfs/scrub/xfile.c b/fs/xfs/scrub/xfile.c
> index a669ebbbc02d1d..2b4819902b4cc3 100644
> --- a/fs/xfs/scrub/xfile.c
> +++ b/fs/xfs/scrub/xfile.c
> @@ -183,11 +183,7 @@ xfile_store(
> loff_t pos)
> {
> struct inode *inode = file_inode(xf->file);
> - struct address_space *mapping = inode->i_mapping;
> - const struct address_space_operations *aops = mapping->a_ops;
> - struct page *page = NULL;
> unsigned int pflags;
> - int error = 0;
>
> if (count > MAX_RW_COUNT)
> return -ENOMEM;
> @@ -196,60 +192,45 @@ xfile_store(
>
> trace_xfile_store(xf, pos, count);
>
> + /*
> + * Increase the file size first so that shmem_get_folio(..., SGP_CACHE),
> + * actually allocates a folio instead of erroring out.
> + */
> + if (pos + count > i_size_read(inode))
> + i_size_write(inode, pos + count);
> +
> pflags = memalloc_nofs_save();
> while (count > 0) {
> - void *fsdata = NULL;
> - void *p, *kaddr;
> + struct folio *folio;
> unsigned int len;
> - int ret;
> + unsigned int offset;
>
> - len = min_t(ssize_t, count, PAGE_SIZE - offset_in_page(pos));
> -
> - /*
> - * We call write_begin directly here to avoid all the freezer
> - * protection lock-taking that happens in the normal path.
> - * shmem doesn't support fs freeze, but lockdep doesn't know
> - * that and will trip over that.
> - */
> - error = aops->write_begin(NULL, mapping, pos, len, &page,
> - &fsdata);
> - if (error) {
> - error = -ENOMEM;
> + if (shmem_get_folio(inode, pos >> PAGE_SHIFT, &folio,
> + SGP_CACHE) < 0)o
SGP_CACHE is the safest choice, yes. It will tend to do an unnecessary
clear_highpage() which you immediately overwrite with the actual data;
but saves calculating exactly what needs to be zeroed above and below
the data - not worth bothering with, unless shaving off CPU cycles.
> break;
> - }
> -
> - /*
> - * xfile pages must never be mapped into userspace, so we skip
> - * the dcache flush. If the page is not uptodate, zero it
> - * before writing data.
> - */
> - kaddr = page_address(page);
> - if (!PageUptodate(page)) {
> - memset(kaddr, 0, PAGE_SIZE);
> - SetPageUptodate(page);
> - }
> - p = kaddr + offset_in_page(pos);
> - memcpy(p, buf, len);
> -
> - ret = aops->write_end(NULL, mapping, pos, len, len, page,
> - fsdata);
> - if (ret < 0) {
> - error = -ENOMEM;
> + if (filemap_check_wb_err(inode->i_mapping, 0)) {
Hah. I was sceptical what that could ever achieve on shmem (the "wb"
is misleading); but it's an ingenious suggestion from Matthew, to avoid
our current horrid folio+page HWPoison handling. I followed it up a bit,
and it does look as if this filemap_check_wb_err() technique should work
for that; but it's not something I've tried at all.
And that's all I've got to say on the series (I read on, but certainly
did not delve into the folio sorting stuff): looks good, but the
VM_NORESERVE question probably needs attention (and that docbook
comment to mention "locked").
XFS tree stil seems to me the right home for it all.
Hugh
> + folio_unlock(folio);
> + folio_put(folio);
> break;
> }
>
> - if (ret != len) {
> - error = -ENOMEM;
> - break;
> - }
> + offset = offset_in_folio(folio, pos);
> + len = min_t(ssize_t, count, folio_size(folio) - offset);
> + memcpy(folio_address(folio) + offset, buf, len);
> +
> + folio_mark_dirty(folio);
> + folio_unlock(folio);
> + folio_put(folio);
>
> - count -= ret;
> - pos += ret;
> - buf += ret;
> + count -= len;
> + pos += len;
> + buf += len;
> }
> memalloc_nofs_restore(pflags);
>
> - return error;
> + if (count)
> + return -ENOMEM;
> + return 0;
> }
>
> /* Find the next written area in the xfile data for a given offset. */
> --
> 2.39.2
>
>
next prev parent reply other threads:[~2024-02-16 7:40 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 14:34 put the xfs xfile abstraction on a diet v3 Christoph Hellwig
2024-01-29 14:34 ` [PATCH 01/20] mm: move mapping_set_update out of <linux/swap.h> Christoph Hellwig
2024-01-29 14:34 ` [PATCH 02/20] shmem: move shmem_mapping out of line Christoph Hellwig
2024-02-16 6:03 ` Hugh Dickins
2024-01-29 14:34 ` [PATCH 03/20] shmem: set a_ops earlier in shmem_symlink Christoph Hellwig
2024-01-29 14:34 ` [PATCH 04/20] shmem: move the shmem_mapping assert into shmem_get_folio_gfp Christoph Hellwig
2024-01-29 14:34 ` [PATCH 05/20] shmem: export shmem_get_folio Christoph Hellwig
2024-02-16 6:07 ` Hugh Dickins
2024-02-16 13:53 ` Matthew Wilcox
2024-02-19 6:25 ` Christoph Hellwig
2024-01-29 14:34 ` [PATCH 06/20] shmem: export shmem_kernel_file_setup Christoph Hellwig
2024-01-29 16:24 ` Darrick J. Wong
2024-01-29 14:34 ` [PATCH 07/20] shmem: document how to "persist" data when using shmem_*file_setup Christoph Hellwig
2024-01-30 6:06 ` Matthew Wilcox
2024-01-30 8:04 ` Christoph Hellwig
2024-01-30 8:05 ` Christoph Hellwig
2024-01-29 14:34 ` [PATCH 08/20] xfs: remove xfile_stat Christoph Hellwig
2024-01-29 14:34 ` [PATCH 09/20] xfs: remove the xfile_pread/pwrite APIs Christoph Hellwig
2024-01-29 14:34 ` [PATCH 10/20] xfs: don't try to handle non-update pages in xfile_obj_load Christoph Hellwig
2024-01-29 14:34 ` [PATCH 11/20] xfs: shmem_file_setup can't return NULL Christoph Hellwig
2024-01-29 14:34 ` [PATCH 12/20] xfs: don't modify file and inode flags for shmem files Christoph Hellwig
2024-02-16 6:55 ` Hugh Dickins
2024-01-29 14:34 ` [PATCH 13/20] xfs: don't allow highmem pages in xfile mappings Christoph Hellwig
2024-02-16 7:13 ` Hugh Dickins
2024-01-29 14:34 ` [PATCH 14/20] xfs: use shmem_get_folio in xfile_obj_store Christoph Hellwig
2024-02-16 7:40 ` Hugh Dickins [this message]
2024-01-29 14:34 ` [PATCH 15/20] xfs: use shmem_get_folio in in xfile_load Christoph Hellwig
2024-01-29 14:34 ` [PATCH 16/20] xfs: add file_{get,put}_folio Christoph Hellwig
2024-01-29 14:34 ` [PATCH 17/20] xfs: remove xfarray_sortinfo.page_kaddr Christoph Hellwig
2024-01-29 14:35 ` [PATCH 18/20] xfs: fix a comment in xfarray.c Christoph Hellwig
2024-01-29 14:35 ` [PATCH 19/20] xfs: convert xfarray_pagesort to deal with large folios Christoph Hellwig
2024-01-29 14:35 ` [PATCH 20/20] xfs: remove xfile_{get,put}_page Christoph Hellwig
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=8eba6e1d-3e93-9586-17f3-86dcf25f5ae4@google.com \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=chandan.babu@oracle.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox