From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: "Andreas Grünbacher" <andreas.gruenbacher@gmail.com>
Cc: linux-erofs@lists.ozlabs.org,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@lst.de>,
"Darrick J . Wong" <djwong@kernel.org>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v3] iomap: support tail packing inline read
Date: Tue, 20 Jul 2021 20:23:57 +0800 [thread overview]
Message-ID: <YPbAXVois1QpOu7X@B-P7TQMD6M-0146.local> (raw)
In-Reply-To: <CAHpGcM+qhur4C2fLyR-dQx7CvumXVvMAM5NBCCXnL5ve-2qE8w@mail.gmail.com>
On Tue, Jul 20, 2021 at 01:34:58PM +0200, Andreas Grünbacher wrote:
> Am Mo., 19. Juli 2021 um 16:48 Uhr schrieb Gao Xiang
> <hsiangkao@linux.alibaba.com>:
> > This tries to add tail packing inline read to iomap, which can support
> > several inline tail blocks. Similar to the previous approach, it cleans
> > post-EOF in one iteration.
> >
> > The write path remains untouched since EROFS cannot be used for testing.
> > It'd be better to be implemented if upcoming real users care rather than
> > leave untested dead code around.
> >
> > Cc: Christoph Hellwig <hch@lst.de>
> > Cc: Darrick J. Wong <djwong@kernel.org>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Andreas Gruenbacher <andreas.gruenbacher@gmail.com>
> > Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> > ---
> > v2: https://lore.kernel.org/r/YPLdSja%2F4FBsjss%2F@B-P7TQMD6M-0146.local/
> > changes since v2:
> > - update suggestion from Christoph:
> > https://lore.kernel.org/r/YPVe41YqpfGLNsBS@infradead.org/
> >
> > Hi Andreas,
> > would you mind test on the gfs2 side? Thanks in advance!
> >
> > Thanks,
> > Gao Xiang
> >
> > fs/iomap/buffered-io.c | 50 ++++++++++++++++++++++++++----------------
> > fs/iomap/direct-io.c | 11 ++++++----
> > 2 files changed, 38 insertions(+), 23 deletions(-)
> >
> > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> > index 87ccb3438bec..cac8a88660d8 100644
> > --- a/fs/iomap/buffered-io.c
> > +++ b/fs/iomap/buffered-io.c
> > @@ -207,23 +207,22 @@ struct iomap_readpage_ctx {
> >
> > static void
> > iomap_read_inline_data(struct inode *inode, struct page *page,
> > - struct iomap *iomap)
> > + struct iomap *iomap, loff_t pos)
> > {
> > - size_t size = i_size_read(inode);
> > + unsigned int size, poff = offset_in_page(pos);
> > void *addr;
> >
> > - if (PageUptodate(page))
> > - return;
> > -
> > - BUG_ON(page_has_private(page));
> > - BUG_ON(page->index);
> > - BUG_ON(size > PAGE_SIZE - offset_in_page(iomap->inline_data));
> > + /* inline source data must be inside a single page */
> > + BUG_ON(iomap->length > PAGE_SIZE - offset_in_page(iomap->inline_data));
> > + /* handle tail-packing blocks cross the current page into the next */
> > + size = min_t(unsigned int, iomap->length + pos - iomap->offset,
> > + PAGE_SIZE - poff);
> >
> > addr = kmap_atomic(page);
> > - memcpy(addr, iomap->inline_data, size);
> > - memset(addr + size, 0, PAGE_SIZE - size);
> > + memcpy(addr + poff, iomap->inline_data - iomap->offset + pos, size);
> > + memset(addr + poff + size, 0, PAGE_SIZE - poff - size);
> > kunmap_atomic(addr);
> > - SetPageUptodate(page);
> > + iomap_set_range_uptodate(page, poff, PAGE_SIZE - poff);
> > }
> >
> > static inline bool iomap_block_needs_zeroing(struct inode *inode,
> > @@ -246,18 +245,19 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data,
> > unsigned poff, plen;
> > sector_t sector;
> >
> > - if (iomap->type == IOMAP_INLINE) {
> > - WARN_ON_ONCE(pos);
> > - iomap_read_inline_data(inode, page, iomap);
> > - return PAGE_SIZE;
> > - }
> > -
> > - /* zero post-eof blocks as the page may be mapped */
> > iop = iomap_page_create(inode, page);
>
> We can skip creating the iop when reading the entire page.
As I said before, I think it can be in a separated patch like
https://lore.kernel.org/r/YPMkKfegS+9KzEhK@casper.infradead.org/
and Christoph said it should be careful:
https://lore.kernel.org/r/YPVfxn6%2FoCPBZpKu@infradead.org/
Thanks,
Gao Xiang
WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: "Andreas Grünbacher" <andreas.gruenbacher@gmail.com>
Cc: "Darrick J . Wong" <djwong@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
linux-erofs@lists.ozlabs.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH v3] iomap: support tail packing inline read
Date: Tue, 20 Jul 2021 20:23:57 +0800 [thread overview]
Message-ID: <YPbAXVois1QpOu7X@B-P7TQMD6M-0146.local> (raw)
In-Reply-To: <CAHpGcM+qhur4C2fLyR-dQx7CvumXVvMAM5NBCCXnL5ve-2qE8w@mail.gmail.com>
On Tue, Jul 20, 2021 at 01:34:58PM +0200, Andreas Grünbacher wrote:
> Am Mo., 19. Juli 2021 um 16:48 Uhr schrieb Gao Xiang
> <hsiangkao@linux.alibaba.com>:
> > This tries to add tail packing inline read to iomap, which can support
> > several inline tail blocks. Similar to the previous approach, it cleans
> > post-EOF in one iteration.
> >
> > The write path remains untouched since EROFS cannot be used for testing.
> > It'd be better to be implemented if upcoming real users care rather than
> > leave untested dead code around.
> >
> > Cc: Christoph Hellwig <hch@lst.de>
> > Cc: Darrick J. Wong <djwong@kernel.org>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Andreas Gruenbacher <andreas.gruenbacher@gmail.com>
> > Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
> > ---
> > v2: https://lore.kernel.org/r/YPLdSja%2F4FBsjss%2F@B-P7TQMD6M-0146.local/
> > changes since v2:
> > - update suggestion from Christoph:
> > https://lore.kernel.org/r/YPVe41YqpfGLNsBS@infradead.org/
> >
> > Hi Andreas,
> > would you mind test on the gfs2 side? Thanks in advance!
> >
> > Thanks,
> > Gao Xiang
> >
> > fs/iomap/buffered-io.c | 50 ++++++++++++++++++++++++++----------------
> > fs/iomap/direct-io.c | 11 ++++++----
> > 2 files changed, 38 insertions(+), 23 deletions(-)
> >
> > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> > index 87ccb3438bec..cac8a88660d8 100644
> > --- a/fs/iomap/buffered-io.c
> > +++ b/fs/iomap/buffered-io.c
> > @@ -207,23 +207,22 @@ struct iomap_readpage_ctx {
> >
> > static void
> > iomap_read_inline_data(struct inode *inode, struct page *page,
> > - struct iomap *iomap)
> > + struct iomap *iomap, loff_t pos)
> > {
> > - size_t size = i_size_read(inode);
> > + unsigned int size, poff = offset_in_page(pos);
> > void *addr;
> >
> > - if (PageUptodate(page))
> > - return;
> > -
> > - BUG_ON(page_has_private(page));
> > - BUG_ON(page->index);
> > - BUG_ON(size > PAGE_SIZE - offset_in_page(iomap->inline_data));
> > + /* inline source data must be inside a single page */
> > + BUG_ON(iomap->length > PAGE_SIZE - offset_in_page(iomap->inline_data));
> > + /* handle tail-packing blocks cross the current page into the next */
> > + size = min_t(unsigned int, iomap->length + pos - iomap->offset,
> > + PAGE_SIZE - poff);
> >
> > addr = kmap_atomic(page);
> > - memcpy(addr, iomap->inline_data, size);
> > - memset(addr + size, 0, PAGE_SIZE - size);
> > + memcpy(addr + poff, iomap->inline_data - iomap->offset + pos, size);
> > + memset(addr + poff + size, 0, PAGE_SIZE - poff - size);
> > kunmap_atomic(addr);
> > - SetPageUptodate(page);
> > + iomap_set_range_uptodate(page, poff, PAGE_SIZE - poff);
> > }
> >
> > static inline bool iomap_block_needs_zeroing(struct inode *inode,
> > @@ -246,18 +245,19 @@ iomap_readpage_actor(struct inode *inode, loff_t pos, loff_t length, void *data,
> > unsigned poff, plen;
> > sector_t sector;
> >
> > - if (iomap->type == IOMAP_INLINE) {
> > - WARN_ON_ONCE(pos);
> > - iomap_read_inline_data(inode, page, iomap);
> > - return PAGE_SIZE;
> > - }
> > -
> > - /* zero post-eof blocks as the page may be mapped */
> > iop = iomap_page_create(inode, page);
>
> We can skip creating the iop when reading the entire page.
As I said before, I think it can be in a separated patch like
https://lore.kernel.org/r/YPMkKfegS+9KzEhK@casper.infradead.org/
and Christoph said it should be careful:
https://lore.kernel.org/r/YPVfxn6%2FoCPBZpKu@infradead.org/
Thanks,
Gao Xiang
next prev parent reply other threads:[~2021-07-20 12:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-19 14:47 [PATCH v3] iomap: support tail packing inline read Gao Xiang
2021-07-19 14:47 ` Gao Xiang
2021-07-19 15:02 ` Matthew Wilcox
2021-07-19 15:02 ` Matthew Wilcox
2021-07-19 15:13 ` Christoph Hellwig
2021-07-19 15:13 ` Christoph Hellwig
2021-07-19 16:11 ` Gao Xiang
2021-07-19 16:11 ` Gao Xiang
2021-07-19 16:31 ` Matthew Wilcox
2021-07-19 16:45 ` Gao Xiang
2021-07-19 16:45 ` Gao Xiang
2021-07-19 15:29 ` Gao Xiang
2021-07-19 15:29 ` Gao Xiang
2021-07-19 15:31 ` Andreas Grünbacher
2021-07-19 15:31 ` Andreas Grünbacher
2021-07-19 15:36 ` Gao Xiang
2021-07-19 15:36 ` Gao Xiang
2021-07-20 11:23 ` Andreas Grünbacher
2021-07-20 11:23 ` Andreas Grünbacher
2021-07-20 12:10 ` Gao Xiang
2021-07-20 12:10 ` Gao Xiang
2021-07-20 11:34 ` Andreas Grünbacher
2021-07-20 11:34 ` Andreas Grünbacher
2021-07-20 12:23 ` Gao Xiang [this message]
2021-07-20 12:23 ` Gao Xiang
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=YPbAXVois1QpOu7X@B-P7TQMD6M-0146.local \
--to=hsiangkao@linux.alibaba.com \
--cc=andreas.gruenbacher@gmail.com \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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 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.