On Sun, Mar 22, 2015 at 10:06 AM, Boaz Harrosh [off-list ref] wrote:

On 03/20/2015 11:08 PM, Rik van Riel wrote:

quoted

On 03/20/2015 04:31 PM, Matthew Wilcox wrote:

<>

quoted

quoted

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.