On 05/07/2015 10:42 AM, Dan Williams wrote:
On Thu, May 7, 2015 at 10:36 AM, Ingo Molnar <mingo(a)kernel.org>
> * Dan Williams <dan.j.williams(a)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.