* bio_vec, bv_page and folios
@ 2024-01-02 8:56 David Howells
2024-01-02 9:15 ` Matthew Wilcox
2024-01-02 10:03 ` David Howells
0 siblings, 2 replies; 4+ messages in thread
From: David Howells @ 2024-01-02 8:56 UTC (permalink / raw)
To: Christoph Hellwig, Matthew Wilcox
Cc: dhowells, linux-fsdevel, linux-mm, linux-kernel
Hi Christoph, Willy,
Will bv_page in struct bio_vec ever become a folio pointer rather than I page
pointer? I'm guessing not as it still presumably needs to be able to point to
non-folio pages.
David
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: bio_vec, bv_page and folios
2024-01-02 8:56 bio_vec, bv_page and folios David Howells
@ 2024-01-02 9:15 ` Matthew Wilcox
2024-01-02 10:03 ` David Howells
1 sibling, 0 replies; 4+ messages in thread
From: Matthew Wilcox @ 2024-01-02 9:15 UTC (permalink / raw)
To: David Howells; +Cc: Christoph Hellwig, linux-fsdevel, linux-mm, linux-kernel
On Tue, Jan 02, 2024 at 08:56:46AM +0000, David Howells wrote:
> Hi Christoph, Willy,
>
> Will bv_page in struct bio_vec ever become a folio pointer rather than I page
> pointer? I'm guessing not as it still presumably needs to be able to point to
> non-folio pages.
My plan for bio_vec is that it becomes phyr -- a physical address +
length. No more page or folio reference.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: bio_vec, bv_page and folios
2024-01-02 8:56 bio_vec, bv_page and folios David Howells
2024-01-02 9:15 ` Matthew Wilcox
@ 2024-01-02 10:03 ` David Howells
2024-01-02 10:24 ` Matthew Wilcox
1 sibling, 1 reply; 4+ messages in thread
From: David Howells @ 2024-01-02 10:03 UTC (permalink / raw)
To: Matthew Wilcox
Cc: dhowells, Christoph Hellwig, linux-fsdevel, linux-mm,
linux-kernel
Matthew Wilcox <willy@infradead.org> wrote:
> On Tue, Jan 02, 2024 at 08:56:46AM +0000, David Howells wrote:
> > Hi Christoph, Willy,
> >
> > Will bv_page in struct bio_vec ever become a folio pointer rather than I page
> > pointer? I'm guessing not as it still presumably needs to be able to point to
> > non-folio pages.
>
> My plan for bio_vec is that it becomes phyr -- a physical address +
> length. No more page or folio reference.
Interesting... What does that mean for those places that currently use
bv_page as a place to stash a pointer to the page and use it to clean up the
page later?
David
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: bio_vec, bv_page and folios
2024-01-02 10:03 ` David Howells
@ 2024-01-02 10:24 ` Matthew Wilcox
0 siblings, 0 replies; 4+ messages in thread
From: Matthew Wilcox @ 2024-01-02 10:24 UTC (permalink / raw)
To: David Howells; +Cc: Christoph Hellwig, linux-fsdevel, linux-mm, linux-kernel
On Tue, Jan 02, 2024 at 10:03:58AM +0000, David Howells wrote:
> Matthew Wilcox <willy@infradead.org> wrote:
>
> > On Tue, Jan 02, 2024 at 08:56:46AM +0000, David Howells wrote:
> > > Hi Christoph, Willy,
> > >
> > > Will bv_page in struct bio_vec ever become a folio pointer rather than I page
> > > pointer? I'm guessing not as it still presumably needs to be able to point to
> > > non-folio pages.
> >
> > My plan for bio_vec is that it becomes phyr -- a physical address +
> > length. No more page or folio reference.
>
> Interesting... What does that mean for those places that currently use
> bv_page as a place to stash a pointer to the page and use it to clean up the
> page later?
I don't intend to get rid of bio_for_each_folio_all() or bio_add_page()
for example. It's just a phys_to_page() away. The advantage is that
we wouldn't need a struct page to do I/O to a physical address.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-01-02 10:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-02 8:56 bio_vec, bv_page and folios David Howells
2024-01-02 9:15 ` Matthew Wilcox
2024-01-02 10:03 ` David Howells
2024-01-02 10:24 ` Matthew Wilcox
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).