From: Matthew Wilcox <willy@infradead.org>
To: Chris Mason <clm@fb.com>
Cc: "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"jlayton@kernel.org" <jlayton@kernel.org>,
"hch@infradead.org" <hch@infradead.org>
Subject: Re: [RFC 0/8] Replacing the readpages a_op
Date: Mon, 13 Jan 2020 09:54:36 -0800 [thread overview]
Message-ID: <20200113175436.GC332@bombadil.infradead.org> (raw)
In-Reply-To: <6CA4CD96-0812-4261-8FF9-CD28AA2EC38A@fb.com>
On Mon, Jan 13, 2020 at 04:42:10PM +0000, Chris Mason wrote:
> Btrfs basically does this now, honestly iomap isn't that far away.
> Given how sensible iomap is for this, I'd rather see us pile into that
> abstraction than try to pass pagevecs for large ranges. Otherwise, if
I completely misread this at first and thought you were proposing we
pass a bio_vec to ->readahead. Initially, this is a layering violation,
completely unnecessary to have all these extra offset/size fields being
allocated and passed around. But ... the bio_vec and the skb_frag_t are
now the same data structure, so both block and network use it. It may
make sense to have this as the common data structure for 'unit of IO'.
The bio supports having the bi_vec allocated externally to the data
structure while the skbuff would need to copy the array.
Maybe we need a more neutral name than bio_vec so as to not upset people.
page_frag, perhaps [1].
[1] Yes, I know about the one in include/linux/mm_types_task.h
next prev parent reply other threads:[~2020-01-13 17:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-13 15:37 [RFC 0/8] Replacing the readpages a_op Matthew Wilcox
2020-01-13 15:37 ` [PATCH 1/8] pagevec: Add an iterator Matthew Wilcox
2020-01-13 15:37 ` [PATCH 2/8] mm: Fix the return type of __do_page_cache_readahead Matthew Wilcox
2020-01-13 15:37 ` [PATCH 3/8] mm: Use a pagevec for readahead Matthew Wilcox
2020-01-13 15:37 ` [PATCH 4/8] mm/fs: Add a_ops->readahead Matthew Wilcox
2020-01-13 18:22 ` Daniel Wagner
2020-01-13 19:17 ` Matthew Wilcox
2020-01-13 15:37 ` [PATCH 5/8] iomap,xfs: Convert from readpages to readahead Matthew Wilcox
2020-01-13 15:37 ` [PATCH 6/8] cifs: " Matthew Wilcox
2020-01-13 15:37 ` [PATCH 7/8] mm: Remove add_to_page_cache_locked Matthew Wilcox
2020-01-13 15:37 ` [PATCH 8/8] mm: Unify all add_to_page_cache variants Matthew Wilcox
2020-01-13 16:42 ` [RFC 0/8] Replacing the readpages a_op Chris Mason
2020-01-13 17:40 ` Matthew Wilcox
2020-01-13 18:00 ` Chris Mason
2020-01-13 21:58 ` Matthew Wilcox
2020-01-13 22:00 ` Jens Axboe
2020-01-13 22:10 ` Matthew Wilcox
2020-01-13 22:14 ` Jens Axboe
2020-01-13 22:27 ` Matthew Wilcox
2020-01-13 22:30 ` Jens Axboe
2020-01-13 22:34 ` Chris Mason
2020-01-14 1:01 ` Matthew Wilcox
2020-01-14 1:07 ` Chris Mason
2020-01-13 17:54 ` Matthew Wilcox [this message]
2020-01-13 22:19 ` Jens Axboe
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=20200113175436.GC332@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=clm@fb.com \
--cc=hch@infradead.org \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@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 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).