On 03/20/2015 11:08 PM, Rik van Riel wrote: > On 03/20/2015 04:31 PM, Matthew Wilcox wrote: <> >> There's a lot of code out there that relies on struct page being PAGE_SIZE >> bytes. I'm cool with replacing 'struct page' with 'struct superpage' >> [1] in the biovec and auditing all of the code which touches it ... but >> that's going to be a lot of code! I'm not sure it's less code than >> going directly to 'just do I/O on PFNs'. > > Totally agreed here. I see absolutely no advantage to teaching the > IO layer about a "struct superpage" when it could operate on PFNs > just as easily. > Or teaching 'struct page' to be variable length, This is already so at bio and sg level so you fixed nothing. Moving to pfn's only means that all this unnamed code above that "relies on struct page being PAGE_SIZE" is now not allowed to interfaced with bio and sg list. Which in current code and in Dan's patches means two tons of BUG_ONS and return -ENOTSUPP . For all these subsystems below the bio and sglist that operate on page_structs Say the "relies on struct page being PAGE_SIZE" is such an hard work, which is not at all at the bio and sg-list level, will it not be worth while fixing this instead of alienating the all Kernel from the IO subsystem. But I believe it is the much much smaller change? Specially considering Networking, RDMA shared memory ... Cheers Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html