Re: [RFC PATCH 0/7] evacuate struct page from the block layer

[Dan Williams]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/