linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/15] fs: Introduce i_blocks_per_page
Date: Wed, 25 Sep 2019 18:36:50 +1000	[thread overview]
Message-ID: <20190925083650.GE804@dread.disaster.area> (raw)
In-Reply-To: <20190925005214.27240-3-willy@infradead.org>

On Tue, Sep 24, 2019 at 05:52:01PM -0700, Matthew Wilcox wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> 
> This helper is useful for both large pages in the page cache and for
> supporting block size larger than page size.  Convert some example
> users (we have a few different ways of writing this idiom).
> 
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>

I'm actually working on abstrcting this code from both block size
and page size via the helpers below. We ahve need to support block
size > page size, and so that requires touching a bunch of all the
same code as this patchset. I'm currently trying to combine your
last patch set with my patchset so I can easily test allocating 64k
page cache pages on a 64k block size filesystem on a 4k page size
machine with XFS....

/*
 * Return the chunk size we should use for page cache based operations.
 * This supports both large block sizes and variable page sizes based on the
 * restriction that order-n blocks and page cache pages are order-n file offset
 * aligned.
 *
 * This will return the inode block size for block size < page_size(page),
 * otherwise it will return page_size(page).
 */
static inline unsigned
iomap_chunk_size(struct inode *inode, struct page *page)
{
        return min_t(unsigned, page_size(page), i_blocksize(inode));
}

static inline unsigned
iomap_chunk_bits(struct inode *inode, struct page *page)
{
        return min_t(unsigned, page_shift(page), inode->i_blkbits);
}

static inline unsigned
iomap_chunks_per_page(struct inode *inode, struct page *page)
{
        return page_size(page) >> inode->i_blkbits;
}

Basically, the process is to convert the iomap code over to
iterating "chunks" rather than blocks or pages, and then allocate
a struct iomap_page according to the difference between page and
block size....

> ---
>  fs/iomap/buffered-io.c  |  4 ++--
>  fs/jfs/jfs_metapage.c   |  2 +-
>  fs/xfs/xfs_aops.c       |  8 ++++----
>  include/linux/pagemap.h | 13 +++++++++++++
>  4 files changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index e25901ae3ff4..0e76a4b6d98a 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -24,7 +24,7 @@ iomap_page_create(struct inode *inode, struct page *page)
>  {
>  	struct iomap_page *iop = to_iomap_page(page);
>  
> -	if (iop || i_blocksize(inode) == PAGE_SIZE)
> +	if (iop || i_blocks_per_page(inode, page) <= 1)
>  		return iop;

That also means checks like these become:

	if (iop || iomap_chunks_per_page(inode, page) <= 1)

as a single file can now have multiple pages per block, a page per
block and multiple blocks per page as the page size changes...

I'd like to only have to make one pass over this code to abstract
out page and block sizes, so I'm guessing we'll need to do some
co-ordination here....

> @@ -636,4 +636,17 @@ static inline unsigned long dir_pages(struct inode *inode)
>  			       PAGE_SHIFT;
>  }
>  
> +/**
> + * i_blocks_per_page - How many blocks fit in this page.
> + * @inode: The inode which contains the blocks.
> + * @page: The (potentially large) page.
> + *
> + * Context: Any context.
> + * Return: The number of filesystem blocks covered by this page.
> + */
> +static inline
> +unsigned int i_blocks_per_page(struct inode *inode, struct page *page)
> +{
> +	return page_size(page) >> inode->i_blkbits;
> +}
>  #endif /* _LINUX_PAGEMAP_H */

It also means that we largely don't need to touch mm headers as
all the helpers end up being iomap specific and private...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2019-09-25  8:36 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-25  0:51 [RFC 00/15] Large pages in the page-cache Matthew Wilcox
2019-09-25  0:52 ` [PATCH 01/15] mm: Use vm_fault error code directly Matthew Wilcox
2019-09-26 13:55   ` Kirill A. Shutemov
2019-09-25  0:52 ` [PATCH 02/15] fs: Introduce i_blocks_per_page Matthew Wilcox
2019-09-25  8:36   ` Dave Chinner [this message]
2019-10-04 19:28     ` Matthew Wilcox
2019-10-08  3:53       ` Dave Chinner
2019-09-25  0:52 ` [PATCH 03/15] mm: Add file_offset_of_ helpers Matthew Wilcox
2019-09-26 14:02   ` Kirill A. Shutemov
2019-10-04 19:39     ` Matthew Wilcox
2019-09-25  0:52 ` [PATCH 04/15] iomap: Support large pages Matthew Wilcox
2019-09-25  0:52 ` [PATCH 05/15] xfs: " Matthew Wilcox
2019-09-25  0:52 ` [PATCH 06/15] xfs: Pass a page to xfs_finish_page_writeback Matthew Wilcox
2019-09-25  0:52 ` [PATCH 07/15] mm: Make prep_transhuge_page tail-callable Matthew Wilcox
2019-09-26 14:13   ` Kirill A. Shutemov
2019-09-25  0:52 ` [PATCH 08/15] mm: Add __page_cache_alloc_order Matthew Wilcox
2019-09-26 14:15   ` Kirill A. Shutemov
2019-09-25  0:52 ` [PATCH 09/15] mm: Allow large pages to be added to the page cache Matthew Wilcox
2019-09-26 14:22   ` Kirill A. Shutemov
2019-09-25  0:52 ` [PATCH 10/15] mm: Allow find_get_page to be used for large pages Matthew Wilcox
2019-10-01 10:32   ` Kirill A. Shutemov
2019-09-25  0:52 ` [PATCH 11/15] mm: Remove hpage_nr_pages Matthew Wilcox
2019-10-01 10:35   ` Kirill A. Shutemov
2019-09-25  0:52 ` [PATCH 12/15] mm: Support removing arbitrary sized pages from mapping Matthew Wilcox
2019-10-01 10:39   ` Kirill A. Shutemov
2019-09-25  0:52 ` [PATCH 13/15] mm: Add a huge page fault handler for files Matthew Wilcox
2019-10-01 10:42   ` Kirill A. Shutemov
2019-09-25  0:52 ` [PATCH 14/15] mm: Align THP mappings for non-DAX Matthew Wilcox
2019-10-01 10:45   ` Kirill A. Shutemov
2019-10-01 11:21     ` William Kucharski
2019-10-01 11:32       ` Kirill A. Shutemov
2019-10-01 12:18         ` William Kucharski
2019-10-01 14:20           ` Kirill A. Shutemov
2019-10-01 16:08             ` William Kucharski
2019-10-02  0:15               ` Kirill A. Shutemov
2019-09-25  0:52 ` [PATCH 15/15] xfs: Use filemap_huge_fault Matthew Wilcox
     [not found] ` <20191002130753.7680-1-hdanton@sina.com>
2019-10-04 19:33   ` [PATCH 03/15] mm: Add file_offset_of_ helpers Matthew Wilcox
     [not found] ` <20191002133211.15696-1-hdanton@sina.com>
2019-10-04 19:34   ` [PATCH 04/15] iomap: Support large pages Matthew Wilcox
     [not found] ` <20191003040846.17604-1-hdanton@sina.com>
2019-10-04 19:35   ` [PATCH 06/15] xfs: Pass a page to xfs_finish_page_writeback Matthew Wilcox
     [not found] ` <20191003050859.18140-1-hdanton@sina.com>
2019-10-04 19:36   ` [PATCH 11/15] mm: Remove hpage_nr_pages Matthew Wilcox

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=20190925083650.GE804@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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;
as well as URLs for NNTP newsgroup(s).