From: Matthew Wilcox <willy@infradead.org>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: linux-erofs@lists.ozlabs.org, linux-fsdevel@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
"Darrick J. Wong" <djwong@kernel.org>,
Christoph Hellwig <hch@infradead.org>, Chao Yu <chao@kernel.org>,
Liu Bo <bo.liu@linux.alibaba.com>,
Joseph Qi <joseph.qi@linux.alibaba.com>,
Liu Jiang <gerry@linux.alibaba.com>
Subject: Re: [PATCH 1/2] iomap: support tail packing inline read
Date: Fri, 16 Jul 2021 14:02:29 +0100 [thread overview]
Message-ID: <YPGDZYT9OxdgNYf2@casper.infradead.org> (raw)
In-Reply-To: <20210716050724.225041-2-hsiangkao@linux.alibaba.com>
On Fri, Jul 16, 2021 at 01:07:23PM +0800, Gao Xiang wrote:
> This tries to add tail packing inline read to iomap. Different from
> the previous approach, it only marks the block range uptodate in the
> page it covers.
Why? This path is called under two circumstances: readahead and readpage.
In both cases, we're trying to bring the entire page uptodate. The inline
extent is always the tail of the file, so we may as well zero the part of
the page past the end of file and mark the entire page uptodate instead
and leaving the end of the page !uptodate.
I see the case where, eg, we have the first 2048 bytes of the file
out-of-inode and then 20 bytes in the inode. So we'll create the iop
for the head of the file, but then we may as well finish the entire
PAGE_SIZE chunk as part of this iteration rather than update 2048-3071
as being uptodate and leave the 3072-4095 block for a future iteration.
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Gao Xiang <hsiangkao@linux.alibaba.com>
Cc: "Darrick J. Wong" <djwong@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Christoph Hellwig <hch@infradead.org>,
Joseph Qi <joseph.qi@linux.alibaba.com>,
Liu Bo <bo.liu@linux.alibaba.com>,
linux-fsdevel@vger.kernel.org,
Liu Jiang <gerry@linux.alibaba.com>,
linux-erofs@lists.ozlabs.org
Subject: Re: [PATCH 1/2] iomap: support tail packing inline read
Date: Fri, 16 Jul 2021 14:02:29 +0100 [thread overview]
Message-ID: <YPGDZYT9OxdgNYf2@casper.infradead.org> (raw)
In-Reply-To: <20210716050724.225041-2-hsiangkao@linux.alibaba.com>
On Fri, Jul 16, 2021 at 01:07:23PM +0800, Gao Xiang wrote:
> This tries to add tail packing inline read to iomap. Different from
> the previous approach, it only marks the block range uptodate in the
> page it covers.
Why? This path is called under two circumstances: readahead and readpage.
In both cases, we're trying to bring the entire page uptodate. The inline
extent is always the tail of the file, so we may as well zero the part of
the page past the end of file and mark the entire page uptodate instead
and leaving the end of the page !uptodate.
I see the case where, eg, we have the first 2048 bytes of the file
out-of-inode and then 20 bytes in the inode. So we'll create the iop
for the head of the file, but then we may as well finish the entire
PAGE_SIZE chunk as part of this iteration rather than update 2048-3071
as being uptodate and leave the 3072-4095 block for a future iteration.
next prev parent reply other threads:[~2021-07-16 13:04 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-16 5:07 [PATCH 0/2] erofs: iomap support for tailpacking cases Gao Xiang
2021-07-16 5:07 ` Gao Xiang
2021-07-16 5:07 ` [PATCH 1/2] iomap: support tail packing inline read Gao Xiang
2021-07-16 5:07 ` Gao Xiang
2021-07-16 9:19 ` Christoph Hellwig
2021-07-16 9:19 ` Christoph Hellwig
2021-07-16 9:46 ` Gao Xiang
2021-07-16 9:46 ` Gao Xiang
2021-07-16 13:47 ` Matthew Wilcox
2021-07-16 13:47 ` Matthew Wilcox
2021-07-16 14:38 ` Matthew Wilcox
2021-07-16 14:38 ` Matthew Wilcox
2021-07-16 13:02 ` Matthew Wilcox [this message]
2021-07-16 13:02 ` Matthew Wilcox
2021-07-16 13:56 ` Gao Xiang
2021-07-16 13:56 ` Gao Xiang
2021-07-16 14:44 ` Matthew Wilcox
2021-07-16 15:03 ` Gao Xiang
2021-07-16 15:03 ` Gao Xiang
2021-07-16 15:53 ` Andreas Grünbacher
2021-07-16 15:53 ` Andreas Grünbacher
2021-07-17 13:38 ` Gao Xiang
2021-07-17 13:38 ` Gao Xiang
2021-07-17 15:01 ` Matthew Wilcox
2021-07-17 15:15 ` Gao Xiang
2021-07-17 15:15 ` Gao Xiang
2021-07-17 18:40 ` Matthew Wilcox
2021-07-19 11:19 ` Christoph Hellwig
2021-07-19 11:19 ` Christoph Hellwig
2021-07-19 13:45 ` Gao Xiang
2021-07-19 13:45 ` Gao Xiang
2021-07-19 11:15 ` Christoph Hellwig
2021-07-19 13:31 ` Gao Xiang
2021-07-19 13:31 ` Gao Xiang
2021-07-16 5:07 ` [PATCH 2/2] erofs: convert all uncompressed cases to iomap Gao Xiang
2021-07-16 5:07 ` Gao Xiang
2021-07-18 5:30 ` kernel test robot
2021-07-18 5:30 ` [RFC PATCH] erofs: erofs_iomap_end() can be static kernel test robot
2021-07-18 16:53 ` 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=YPGDZYT9OxdgNYf2@casper.infradead.org \
--to=willy@infradead.org \
--cc=bo.liu@linux.alibaba.com \
--cc=chao@kernel.org \
--cc=djwong@kernel.org \
--cc=gerry@linux.alibaba.com \
--cc=hch@infradead.org \
--cc=hsiangkao@linux.alibaba.com \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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.