Re: [PATCH v2 00/10] evacuate struct page from the block layer, introduce __pfn_t

[Dave Hansen <dave.hansen@linux.intel.com>]

On 05/07/2015 10:42 AM, Dan Williams wrote:
> On Thu, May 7, 2015 at 10:36 AM, Ingo Molnar <mingo@kernel.org> wrote:
>> * Dan Williams <dan.j.williams@intel.com> wrote:
>> So is there anything fundamentally wrong about creating struct page
>> backing at mmap() time (and making sure aliased mmaps share struct
>> page arrays)?
> 
> Something like "get_user_pages() triggers memory hotplug for
> persistent memory", so they are actual real struct pages?  Can we do
> memory hotplug at that granularity?

We've traditionally limited them to SECTION_SIZE granularity, which is
128MB IIRC.  There are also assumptions in places that you can do page++
within a MAX_ORDER block if !CONFIG_HOLES_IN_ZONE.

But, in all practicality, a lot of those places are in code like the
buddy allocator.  If your PTEs all have _PAGE_SPECIAL set and we're not
ever expecting these fake 'struct page's to hit these code paths, it
probably doesn't matter.

You can probably get away with just allocating PAGE_SIZE worth of
'struct page' (which is 64) and mapping it in to vmemmap[].  The worst
case is that you'll eat 1 page of space for each outstanding page of
I/O.  That's a lot better than 2MB of temporary 'struct page' space per
page of I/O that it would take with a traditional hotplug operation.