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@xxxxxxx/
