Re: brd in a memdesc world

[Matthew Wilcox <willy@infradead.org>]

On Wed, Mar 13, 2024 at 06:15:26PM +0100, Pankaj Raghav wrote:
> On 12/03/2024 18:40, Matthew Wilcox wrote:
> > Hi Jens,
> > 
> > I'm looking for an architecture-level decision on what the brd driver
> > should look like once struct page has been shrunk to a minimal size
> > (more detail at https://protect2.fireeye.com/v1/url?k=fdf5d9a0-9c7ecc9a-fdf452ef-74fe4860008a-d5306bf365c2b9b6&q=1&e=cbceae8b-61fb-4e3e-8f7c-6717d9b2431d&u=https%3A%2F%2Fkernelnewbies.org%2FMatthewWilcox%2FMemdescs )
> > 
> > Currently brd uses page->index as a debugging check.  In the memdesc
> > future, struct page has no members (you could store a small amount of
> > information in it, but I'm not willing to commit to more than a few bits).
> > 
> 
> Shouldn't we change brd to use folios? Once we do that, this will not
> be a problem any more right?

We certainly could change brd to use folios.  But why would we want to?
Hannes' work always allocates memory of a fixed size (a fixed multiple
of PAGE_SIZE).  Folios are a medium-weight data structure (probably
about 80 bytes once we get to memdescs).  They support a lot of things,
eg belonging to an inode, having an index, being mappable to userspace,
being lockable, accountable to memcgs, allowing extra private data,
knowing their own size, ...

None of those things are needed for brd's uses.  All brd needs is to
be able to allocate, kmap and free chunks of memory.  Unless there are
plans to do more than this.