Received-SPF: pass (google.com: domain of linux-kernel+bounces-14238-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Tue, 2 Jan 2024 10:24:23 +0000
From: Matthew Wilcox <willy@infradead.org>
To: David Howells <dhowells@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: bio_vec, bv_page and folios
Message-ID: <ZZPkV2KU/dHvBB3d@casper.infradead.org>
References: <ZZPUKHTQ//eL53SM@casper.infradead.org>
 <3490948.1704185806@warthog.procyon.org.uk>
 <5779.1704189838@warthog.procyon.org.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5779.1704189838@warthog.procyon.org.uk>

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.