Re: brd in a memdesc world

[Pankaj Raghav <p.raghav@samsung.com>]

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?

Hannes even had patches around it long time back [1]

> brd doesn't use anything else from struct page, as far as I can tell.
> It just calls kmap_atomic() / __free_page() / flush_dcache_page() (and
> it doesn't need to call flush_dcache_page() because you can't mmap the
> pages in the brd's array).
> 
> Now if you have plans to, eg, support page migration, you're going to need
> a bit more infrastructure than just allocating pages, but for what you
> have at the moment, just removing the debugging checks that page->index ==
> idx would make you entirely compatible with the memdesc future.
> 
> Any problem with that?

[1] https://lore.kernel.org/linux-block/20230306120127.21375-2-hare@suse.de/