On Sun, Mar 22, 2015 at 10:06 AM, Boaz Harrosh <boaz@xxxxxxxxxxxxx> wrote: > 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 I'm not convinced it will be that bad. In hyperbolic terms, continuing to overload struct page means we get to let floppy.c do i/o from pmem, who needs that level of compatibility? Similar to sg_chain support I think it's fine to let sub-systems / archs add pmem i/o support over time. It's a scaling problem our development model is good at. -- 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
